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.

In the modern day, we’ve come to expect that our various applications can share our identity information with one another. Most of our core systems federate seamlessly and bi-directionally. This means that you can quite easily register and log in to a given service with the user account from another service or even invert that process (technically possible, not always advisable). But what is the next step in our evolution towards greater interoperability between our applications, services and systems?

Identity and access management: A long evolution

Identity and access management (IAM) has evolved into a sprawling field of separate but interrelated processes. 

Even before the recent pandemic, both the users of our tech stacks and the servers that host their applications were becoming more and more dispersed and scattered. The pandemic only served to hyper-accelerate that trend. 

As Gartner’s Cybersecurity Chief of Research, Mary Ruddy stated recently, “Digital security is reliant on identity whether we want it to be or not. In a world where users can be anywhere and applications are increasingly distributed across datacenters in the multi-cloud… identity and access is the control plane.”

Add to this the fact that most cybersecurity functions score about 2.5 on Gartner’s five-point maturity scale and we see the usual tech dynamic of convenience forging ahead as security struggles to keep pace. 

To see how these patches of user databases and applications can be stitched together into a united whole and allow for risk and context-based access control across the board, we will explore how identity and access interoperability have evolved from federation standards and protocols until now and how this is evolving forward into a cohesive identity fabric. 

It’s time to learn from the past, evaluate the present and, of course, prepare for the future of IAM.

Past: A history of federation

Dropping into the timeline around the year 1995 lands us in a time when the green shoots of identity interoperability were just starting to show.  

Twelve years and several threads of directory (or user database) research and development culminated around this time, with the emergence of the Lightweight Directory Access Protocol (LDAP) – version 3. This standard became the basis for the Netscape Directory Server in 1996, OpenLDAP in 1998, and the now ubiquitous Microsoft Active Directory in 2000. 

The standard was initially optimized for read rather than write operations and was designed to allow client apps with very limited computing available (less than 16MB RAM and 100 MHz CPU) to query and authenticate users quickly. By achieving this low-overhead functionality, LDAP quickly became the de facto authentication protocol for internet services. 

Inside the integrated Microsoft (MS) estate, Active Directory authenticated credentials against an LDAP directory and granted access to the operating system (OS) and any applications to which a user was entitled. 

Outside the MS estate, single sign-on had to be achieved by reverse proxy servers that authenticated users (usually via LDAP) in a holding pen before redirecting them into the various systems to which they were entitled. Under the hood, this approach tended to combine LDAP, 302 HTTP redirects, and identity information injected into HTTP headers, with cookies used as session tokens. This Web Access Management (WAM) paradigm was effective but somewhat crude and varied greatly from app to app. 

Now that a relatively universal authentication protocol was established, the lack of a standardized way of landing users post-authentication into applications along with user, session or account attributes was in evidence. In addition to this, session tokens based on cookies were only viable intra-domain and not inter-domain. Authorization was even clunkier, with specific endpoints/URLs within applications needing to be HTTP redirected to the auth server, which, in turn, would check against LDAP attributes before allowing the user to see a page or take action. 

SAML 2.0: A circle of trust

By the mid-2000s, threads of research and development (R&D) were coming to fruition, with WS Federation,  Liberty Alliance’s ID-FF 1.1, and the Organization for the Advancement of Structured Information Services (OASIS) Security Assertion Markup Language (SAML) 1.1 being the standout candidates. The latter two, along with Shibolleth, converged and OASIS ratified SAML 2.0 in March 2005.

The concept was to create a circle of trust between a user, a directory, and an application. Administrators on both the application and directory sides could exchange signing certificates to create trust between their two systems.

In an identity-provider-initiated flow, directories can redirect authenticated users into an application from an application launchpad. However, in a service-provider-initiated flow, users can attempt to log in to applications and (typically) be recognized by their email domain and redirected to their home directory to be authenticated there before being redirected back to the app. 

In both cases, users land into an application with a SAML assertion, a piece of XML data that encapsulates their identity data, any other custom fields or attributes like account balance or shopping cart contents, and the x.509 signing certificate mentioned above. 

SAML authorization is most commonly performed by landing a user into an application with roles already defined on the application side, such as standard, manager, developer or administrator. This typically means a user’s allowed/disallowed pages or actions are tied to their role type. 

In SAML 2.0, we finally had an identity federation technology, a standardized way for users from one directory to access multiple applications and (best of all) across different network domains. 

In identity federation, one system plays the role of a directory or user database, and the other system plays the role of the application being accessed, even if both systems are commonly thought of as apps. 

Below are diagrams showing how two of the most widely used enterprise systems that support SAML could federate one way or the other. In one, Salesforce acts as the identity provider (directory or user database) for accessing Azure, and in the other scenario, the roles are reversed. The point is to illustrate how the federation uses combinations of LDAP and SAML to allow users to access a service with their accounts from another service.

Scenario 1

Key:

1. The user chooses an option to sign in to Azure with their Salesforce account.
2. Azure redirects the user to Salesforce for authentication.
3. The user’s credentials are authenticated via LDAP against Salesforce’s directory.
4. Salesforce sends a signed SAML assertion containing the user’s data to Azure to log them in.

Scenario 2

Key:

1. The user chooses an option to sign in to Salesforce with their Azure account.
2. Salesforce redirects the user to Azure for authentication.
3. The user’s credentials are authenticated via LDAP against Azure’s directory.
4. Azure sends a signed SAML assertion containing the user’s data to Salesforce to log them in.

The consumer computing revolution

Beyond the enterprise, the release of iOS in 2007 and Android in 2008 saw an explosion in consumer computing. 

Consider this statistic: in 2010, 37 percent of households owned a computer, but by 2014, 37 percent of individuals owned a smartphone. Across the two mobile OS in 2012 alone, roughly 1.3 billion new apps were shipped, with about 35 billion app downloads distributed across these new apps.

Client-side applications became extremely lightweight — mere viewing and input panes — with the vast majority of the logic, data, and computing residing on the server and injected in over the internet.

The number of application programming interfaces (APIs) mushroomed to cater to a population that increasingly demanded their apps and services be able to share their data with one another, particularly to allow for subscribing to a service with their accounts from another service.

R&D into a consumer computing open identity standard had been underway at Twitter and Google since about 2006 to 2007. During these conversations, experts realized that a similar need existed for an open standard for API access delegation. How could one application grant a certain amount of access to another without sharing credentials (which, in any case, would give total access)?

As Eran Hammer-Lahav explains in his guide to OAuth, “Many luxury cars today come with a valet key. It is a special key you give the parking attendant and, unlike your regular key, will not allow the car to drive more than a mile or two… Regardless of what restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key while using your regular key to unlock everything.”

How does OAuth work?

OAuth was the framework that emerged to solve this problem. It allows users to share data without sharing passwords.

Let’s take a look at what happens on the backend when a photo printing service allows you to share your pictures from an online storage platform instead of requiring you to upload them from your local machine.

Below is an attempt to explain an OAuth authorization flow as simply as possible for a nine-step process. Formal terms for the various parties involved are bracketed. In this process, a user can share images from their Dropbox account with Photobox, an online photograph printing and delivery service. Like in the SAML relationships described earlier, admins from both platforms must establish a backend trust based on a client ID and client secret (instead of an x.509 certificate as in SAML) — this can be thought of as Photobox’s username and password with Dropbox. It describes a scenario where a third-party authorization service (often an IAM platform) is leveraged, but many websites or services may implement their own authorization service.

1. A user opts to share data from one service (data holder) with another service (data requester). The data requester contacts the data holder with a client ID and client secret.
2. Data-holding service redirects the request to an authorization service.
3. The authorization service contacts the user’s browser to have them log in and/or provide consent to share data with the data requester as required. 
4. The user logs in and/or provides consent to share data, often specifying what data can or cannot be shared (scopes).
5. The authorizer redirects back to the data requester with an authorization token.
6. The data requester contacts the authorizer on the backend (not via the user’s browser) with the authorization token plus client ID and client secret.
7. The authorizer responds with an access token specifying the scope of what may or may not be accessed.
8. The data requester sends an access token to the data holder.
9. The data holder responds to the data requester with the scoped content.

SAML authorized users “in advance” by landing users into applications with a specified role, and those applications defined what different roles could or couldn’t do. OAuth allows for much more fine-grained authorization on a per-page or per-action basis. This reflects an expansion from role-based access to a more resource-based access control mentality that emphasizes the thing being accessed over who is doing the accessing.

Registration and authentication

But what about registering and authenticating users? Most people think of OpenID Connect (OIDC) as an extension of OAuth, which is optimized for authentication instead of authorization. OAuth itself, incidentally, appears less keen on this characterization:

“OAuth is not an OpenID extension and at the specification level, shares only a few things with OpenID — some common authors and the fact both are open specification in the realm of authentication and access control.”

While they are used for different purposes — OAuth to authorize, OIDC to authenticate — the fact is that an OIDC flow is an OAuth flow with the addition of identity tokens to the authorization and access tokens.

Let’s look at the flow behind the scenes in a scenario like the one below, where you can register or log in to Airbnb with your Apple ID.

1. The user opts to log in to Airbnb with Apple ID.
2. Airbnb sends a request to the Apple ID service containing Airbnb’s client ID and client secret configured by both platform admins. 
3. The user authenticates against Apple ID’s directory.
4. Apple ID sends an encoded identity JSON Web Token (JWT) to Airbnb that contains the user’s information. Airbnb can decode Apple’s identity token by using a public key. The user’s session is created.

Unlike the OAuth flow described earlier, the resource server/data holder and the authentication service are one and the same organization, with AppleID both holding the data and authorizing its sharing. Alternatively, a third-party IAM platform could be implemented to query an OpenID provider and authenticate against it.

The JSON Web Token

The emergence of the JSON Web Token (JWT) around 2013 was a crucial element in the evolution of identity federation and modern authentication. Essentially a JSON data format with added security features, it defined a secure and standardized format for signing, encrypting, decrypting, and transmitting identity data across domains.

JWTs consist of three parts:

1. Header: Contains fields for type (which is JWT) and the cryptographic algorithm used in the signature in section three (often RSA or SHA256). If services have opted to encrypt as well as sign the JWT, the encryption algorithm will also be specified here.
2. Payload: Contains the actual user information being transmitted in key: value pairs.
3. Signature: This is where the content of the header and payload has the cryptographic algorithm specified in the header applied to ensure its integrity and authenticity. 

This is a sample JWT, encoded and decoded with a header specifying a JWT and the signing algorithm used, a payload specifying a unique ID, a name, and whether the user is an admin, and finally, a signature section.

It’s worth noting that while OAuth implementations may issue authorization and/or access tokens in XML, simple JSON, or JWT formats, OpenID Connect mandates the use of JWTs for identity tokens to ensure the authenticity and integrity of personally identifiable information.

This wraps up the main identity federation and access protocols and frameworks. It’s useful to think in terms of a user that wants to ‘come from’ some directory and ‘go to’ some application in most cases. The terms used in the different protocols vary but can be mapped reasonably well like this:

System for Cross-Domain Identity Management (SCIM)

Outside of access management, one more crucial IAM protocol is worth mentioning. The System for Cross-Domain Identity Management (SCIM) is the most common protocol for identity management. It is used to execute remote creation (provisioning), updating and deletion of users and groups from within an identity platform. It is also extremely useful for allowing developers to build out self-service user journeys such as address/phone/payment updating or password resets. Essentially a REST API optimized for identity governance, it has become a relatively universal standard, with most large cloud platforms now having SCIM endpoints that will accept HTTP POST and PUT requests.

Figure: Typical remote user-create SCIM API call

Present day: The state of identity and access management

The long march from LDAP to SAML, OAuth, OIDC and SCIM has seen profound evolution and interoperability in IAM. These protocols have done much to allow systems to lean on one another to authenticate users, authorize the sharing of resources, or agree on standardized ways to lift and shift user data.

As IBM’s Bob Kalka likes to say, “Identity and access is an amorphous blob that touches on everything.” There are several separate but related processes that IAM admins, engineers and architects must be concerned with. The tooling developed by vendors has grown up to service these processes. Let’s look at the main ones:

1. Orchestrate user journeys across applications, directories, and third-party services (like identity proofers) from the user interface (UI) backward down the stack. The web redirect is still one of the most basic units of work, as users get bounced around between systems to execute user journeys that call on multiple systems. This usually demands that IAM engineers understand front-end web/mobile development and vice versa. 

2. Consume identities from or sync and provision (CRUD — create, read, update, delete) identities into any number of identity sources of varying kinds.

3. Control the provisioning, updating, and deletion of your joiners, movers, and leavers on the application side.

4. Authenticate users into any number of target applications of varying kinds. Things are easier when applications have been built to modern federation specifications like SAML or OpenID Connect. These can then receive identity and account data from directories in a standardized way. However, many organizations do not have the resources to invest in modernizing the applications that do not support these modern protocols. Landing users into these applications securely while populating them with their identity or other account information as necessary (session creation) can be especially challenging.

5. Perform adaptive or context-based access control across the estate. Access policies can be based on static conditional rules related to location, device, user/group attributes, or the pages or actions being accessed. Access management is increasingly leveraging machine-learning algorithms that profile usage patterns and increase their risk score when significant divergence from these patterns is detected. Once these ‘ifs’ are defined, admins can define ‘thens’ that might range from allow, multi-factor authentication (MFA), extra MFA, or block sessions, depending on the riskiness of the user’s session.

6. Integrate IAM with the organization’s Security Operations (SecOps). Most cybersecurity organizations scored 50 percent on a recent Gartner five-point maturity scale for IAM. SecOps and IAM are indeed quite distinct specializations, but the low level of interoperability is surprising. At the very least, it should be taken for granted that your security information and event management (SIEM) is consuming IAM logs. This convergence of disciplines is dubbed identity threat detection and response (ITDR).

7. Control access to privileged systems like server operating systems and root accounts of cloud service providers. These privileged access management (PAM) systems should, at a minimum, vault credentials to these systems. More advanced practices include approval requests, session recording, or credential heartbeats to detect whether credentials have been altered.

This is the point at which IAM stands today: a proliferation of tools, processes, and integrations. To add to that complexity, most organizations’ IAM terrains are fragmented, at least along workforce and consumer lines. There is just as often further fragmentation on a per-business unit, per-product offering, or per-budget basis.

Where can our efforts to further unify this control plane lead us?

Looking Ahead: The identity fabric

Gartner refers to an identity fabric as “a system of systems composed of a blend of modular IAM tools.”

As a discipline, IAM is at a point somewhat reminiscent of the world of SecOps circa 2016. At that time, there were several distinct but interrelated subdisciplines within the Security Operations Centre (SOC). Detection, investigation, and response were perhaps the three main process specializations, as well as product categories. Endpoint detection and response, threat intelligence, and threat hunting were and are swim lanes unto themselves. It was in this context that the need for orchestration processes and SOAR tooling emerged to stitch all of this together.

Given the security ramifications at stake, the evolution toward greater cohesion in IAM must be maintained. This more unified approach is what underpins the identity fabric mentality.

If it is a composable fabric of tools woven together, the orchestration layer is the stitching that weaves that fabric together. It is important to think of orchestration as both a work process and a tool. 

Therefore, an identity fabric constitutes any and all of the seven work processes an organization needs to carry out its use cases — plus an orchestration process. This is how the “centralized control and decentralized enablement” discussed by Gartner is achieved.

IBM tooling across the 7 IAM work processes

IBM’s mission within the IAM space is to allow organizations to connect any user to any resource.

We have, for some time, had the greatest breadth of IAM tools under one roof. We were also the first to offer a single platform that supported both runtime (access management) and administrative (identity governance) workloads in a single product. This product, Verify SaaS, also has the distinction of still being the only platform equally optimized for both workforce and consumer workloads. 

That we have tooling across all seven process categories is a unique differentiator. That we offer a single platform that straddles five of these seven processes is even more unique.

Examining the seven work processes, here is a brief holistic outline of the toolbox:

1. Orchestration

Our new orchestration engine is now available as part of Verify SaaS. It allows you to easily build user journey UIs and use cases in a low-code/no-code environment. On the back end, you can orchestrate directories and applications of all kinds and easily integrate with third-party fraud, risk or identity-proofing tools.

2. Directory integration and federation

IBM’s on-premise directory is the first on the market to support containerized deployments. Virtual Directory functionality allows the consumption of identities from heterogeneous identity sources to present target systems with a single authentication interface. Directory Integrator boasts an unrivaled number of connectors and parsers to read identity records from systems or databases and write them into other required directories. 

3. Identity governance

IBM offers powerful and customizable identity governance platforms in SaaS or software form, as well as out-of-the-box connectors for all the major enterprise applications, along with host adaptors for provisioning into infrastructure operating systems. Additional modules are available for entitlement discovery, separation of duty analysis, compliance reporting, and role mining and optimization.

4. Modern authentication

IBM offers runtime access management platforms available as SaaS or software. Both support SAML and OpenID Connect. The software platform’s heritage is in web access management, so the base module is a reverse proxy server for pre-federation target apps. 

The IBM Application Gateway (IAG) is a special gem in our IAM toolbox. A novel combination of old and new technologies, it allows you to serve a lightweight reverse proxy out of a container. Users are authenticated in via OIDC and out into the target application via reverse proxy. It can front an application that doesn’t support federation. It can also be used to enforce access policies within your custom application based on URL paths, hostnames and HTTP methods. Available at no extra cost with any Verify Access or Verify SaaS entitlement, it is now available as a standalone component. The Application Gateway allows you to modernize how your custom app is consumed without needing to invest in the modernization of the app itself. 

5. Adaptive access

Trusteer is IBM’s fraud detection solution. It ingests over 200 data criteria to risk score user behaviour, such as time, typing, mouse patterns, browser or OS information, and virtual machine (VM) detection. Available to deploy standalone within your front-end applications, Verify Access and Verify SaaS can also leverage Trusteer’s machine learning algorithm to risk score a user session at authentication time. 

6. Identity threat detection and response

In addition to the Verify products’ native threat detection capabilities, they can easily integrate with the IBM X-Force threat intelligence platform and other third-party risk services. This data can be leveraged to immediately reject common or compromised credentials or requests from known malicious IP addresses. 

7. Privileged access management

To round out the IAM toolbox, Verify Privilege provides credential vaulting and heartbeat, session launchers, and session recording for mission-critical infrastructure operating systems, databases and systems.

Embracing cohesive IAM solutions

In the spirit of composability, IBM offers virtually every kind of IAM tool you could need, along with the orchestration engine that can stitch your identity estate into a cohesive fabric. They are all designed to interoperate with other directories, applications, access managers, or identity governors you may currently have deployed. The unique proposition is that we can provide what is missing, whatever that may be.

Where identity and access have always tended to have been a layer of abstraction within applications or operating systems, the identity fabric paradigm is about decoupling identity and access from applications, directories, and operating systems. The aspiration is for identity to graduate to a layer that floats above systems rather than remain a layer that is embedded within them.

To leave aside tooling and technologies for the final word, implementing the available tooling that facilitates an identity fabric will not automatically make it a reality. Currently, a solution architect is almost as likely as not to believe each solution requires its own directory or access manager, much like most solutions must be underpinned by their own databases. In this context, is it any surprise that IAM processes are so siloed and fragmented?

Contact your in-country technical specialist to book a free identity fabric workshop and discuss how you can evolve your IAM environment into a cohesive security control plane.

The post From federation to fabric: IAM’s evolution 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.

In the ever-evolving fraud landscape, fraudsters have shifted their tactics from using third-party devices to on-device fraud.

Now, users face the rising threat of fraud involving remote access tools (RATs), while banks and fraud detection vendors struggle with new challenges in detecting this invisible threat.

Let’s examine the modus operandi of fraudsters, prevalence rates across different regions, classic detection methods and Trusteer’s innovative approach to RAT detection through behavioral analysis.

A rising threat

Trusteer’s customer data analysis shows that RAT device takeover has become a prevalent form of fraud, constituting a significant proportion of browser-based fraudulent activities in the U.K. and Australia.

This modus operandi started in English-speaking countries and then moved to Spain and Latin America. It has recently surfaced in France and Japan, where it was previously unreported.

Modus operandi: The classic tech support scam

A popular method fraudsters use involves a legitimate RAT, such as Team Viewer or AnyDesk, which allows them to access the victim’s device remotely. These frauds typically involve a social engineering component to convince the user to install the tool and allow the fraudsters to access their device.

Most tech support scams follow these steps:

Step 1: A user is browsing online and is redirected to a malicious website with a pop-up claiming that the device has been infected with malware. The pop-up contains a phone number to a rogue technical support team that can “assist” with “cleaning” the device.

Step 2: The user calls the phone number and is asked to download a RAT and grant the fraudster permission to connect to their device remotely.

Step 3: Next, the legitimate user establishes a banking session to pay for the services. If a one-time password is required to authenticate a new target account identifier, this action is authorized by the victim.

Explore IBM Security Trusteer Solutions

Traditional detection methods

One of the traditional methods to detect RAT is through lower mouse movement frequency.

If on-device mouse movements comprise many small, frequent events, some of these events get lost while transmitting remote mouse movements. This results in fewer measurable events.

The image below illustrates how these movements would look in a graphic form.

However, the rise of remote work during COVID-19 pushed forward many improvements in remote communication tools — RATs included — altering the old detection models.

Challenge accepted: Trusteer’s innovative solution

Trusteer’s research teams have risen to the RAT fraud detection challenge by exploring alternative detection methods. We have identified distinct behavioral patterns unique to each RAT. The unique behavioral “fingerprints” allow Trusteer’s fraud detection products to detect the use of a RAT and identify the specific tool used during the attack.

The following graphic shows the distribution of a specific behavioral event for legitimate and fraudulent sessions. The X-axis represents the number of a distinct behavioral event, leveraging data from user flow, key and mouse elements. The Y-axis represents the probability of seeing this number in fraudulent and legitimate sessions. Our research shows that a high number of events is associated with fraudulent sessions with a specific RAT, which is mainly used in central Europe.

(Source: IBM Trusteer)

These patterns have been recorded in about 20% of fraud sessions using RATs, as opposed to only 0.01% of legitimate sessions. This helps our teams detect RAT-enabled fraud with more certainty.

Stay safe from RAT fraud

RAT fraud has reached every corner of the world while becoming increasingly invisible, posing a challenge to banks and security teams.

However, Trusteer’s fraud detection system, Pinpoint Detect (PPD), can identify fraud sessions involving RATs with remarkable coverage and accuracy based on behavioral analyses.

If you have further questions about RAT fraud, please contact IBM Trusteer Enterprise Support by opening a case in the Customer Portal.

This post was made possible through the contributions of Nir Somech, Andrey Finkelshtein and Dean David Hershkowitz.

The post Remote access detection in 2023: Unmasking invisible fraud 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.

As our lives become increasingly digital, threat actors gain even more avenues of attack. With the average person spending about 400 minutes online, many scammers enjoy a heyday. Old impersonation scams continue to deceive people every day, as con artists and hackers are armed with advanced technologies and sophisticated social engineering tactics.

According to the Federal Trade Commission, financial fraud increased by over 30% from 2021 to 2022, with total losses surpassing $8.8 billion. This ever-evolving threat will continue to pose a real danger to consumers and companies until security teams can adapt to combat it.

What is financial fraud?

Financial fraud is any crime where someone uses illegal or deceptive practices to steal money or otherwise compromise a person or entity’s financial assets or standing.

Typically, most types of fraud involve a scam where the perpetrator uses stolen credentials, documents or authentication methods to deceive authorities and manipulate technology systems for illicit gain.

9 common types of financial fraud

Here are nine of the most common types of financial fraud in 2023:

1. Identity Theft

Identity theft occurs when a criminal steals someone’s personally identifiable information (PII), such as their Social Security number (SSN), name, address or date of birth. With this sensitive data, thieves can impersonate victims to take over online accounts, secure fraudulent loans and commit bank scams.

2. Tax Fraud

Tax fraud is the illegal practice of evading tax obligations. Companies might underreport their income, falsify expenses or otherwise “cook their books” to lower their taxable income. In November 2022, the stars of the reality TV show “Chrisley Knows Best” were sentenced to federal prison after being convicted of defrauding banks out of $30 million.

3. Credit Card Fraud

Credit card fraud is one of the most common types of financial fraud, as thieves can use stolen card information to create fake cards or make unauthorized transfers or purchases online. By 2023, retailers will lose about $130 billion on card-not-present transactions.

4. Romance Scams

In romance scams, impersonators establish online relationships with victims to steal money or personal information. The fraudsters often convince people to invest in a promising cryptocurrency scheme — but the fraudsters control this fraudulent platform. This scam recently cost a Texas widower $2.7 million.

5. Charity Scams

Charity scams happen when fraudsters persuade people to donate money to a fake cause or when the perpetrators misappropriate funds from a bona fide charity. In April 2023, a Utah man was selling flowers and asking for donations — to help a young girl get an organ transplant. After being arrested, he admitted it was a scam.

6. Check Deposit Scams

In check deposit scams, crooks trick people into cashing fake checks and ask them to send a portion of the money back via gift cards or cryptocurrency. A young graduate thought she landed a remote job as her “new employer” sent her a check for home office supplies. But after returning $4,500 in Bitcoin, the check bounced, and her new employer vanished, leaving her with bank debt.

7. Insurance Fraud

Insurance fraud is when someone makes false statements to obtain payments or benefits from insurance companies. For example, a con artist may stage accidents, fake injuries or inflate the cost of damages to get more money from an insurance provider. A Californian security company was charged with insurance fraud after hiding $1.6 million in employee compensation.

8. Deed Fraud

Also known as home title theft, deed fraud is a rare scam where someone forges a property owner’s signature or steals their identity to transfer ownership of the property. Once the thief has a fraudulent deed, they can drain the home equity or sell the property to an innocent buyer. From 2014 to the present, the New York City Sheriff’s Office received almost 3,500 complaints of deed theft.

9. Investment Fraud

Investment fraud has many variations, but most follow the style of a Ponzi scheme, where operators lure people with promises of a no-risk scheme that offers high returns. As more people invest, the operators line their pockets — until the scheme collapses, leaving victims with nothing. In December 2022, eight men were charged with running a pump-and-dump scheme that stole over $100 million in illicit stock market profits.

Protect against fraud

What security teams can do to combat financial fraud

Consumers place a lot of trust in financial institutions to safeguard their money and personal data. It’s up to security teams and developers to create robust applications that can keep consumers safe.

Here are five steps security teams can take to combat financial fraud.

1. Implement Multi-Factor Authentication (MFA)

As a first-line security measure, MFA requires users to provide multiple forms of identification to access an account or system. By insisting employees provide a second identification factor — like biometric scans or a hardware security key — there’s less chance of hackers infiltrating your network.

Action steps:

• Enable MFA for all user accounts, including employees and customers
• Educate users about the importance of MFA and show them how to set it up
• Regularly review and update MFA settings and protocols to stay ahead of evolving threats.

2. Conduct Regular Security Awareness Training

Cybersecurity teams need to be able to stay ahead of emerging threats. Ongoing training educates employees and users about the latest phishing techniques, potential security risks and best practices to avoid becoming a victim of financial fraud.

Action steps:

• Develop comprehensive training programs to keep everyone up-to-date with emerging fraud trends. It’s essential to nurture a strong culture of security awareness throughout the company — not just in the IT department.
• Conduct regular cybersecurity risk assessments to gauge your organization’s readiness for future attacks and plan clear protocols.
• Run war-gaming exercises to detect vulnerabilities in your security system or application before hackers do. This interactive training prepares your team for real attacks.

3. Improve Real-Time Transaction Monitoring

You can use advanced analytics and automated systems to analyze all activity on your app. By keeping a close eye on financial transactions in real-time, you can identify early warning signs and stop potential fraud before it’s too late.

Action steps:

• Set up alerts to warn security teams about suspicious activities, such as unusually high transactions on a customer’s credit card account. NIST AU-2 guidelines outline common audit events to consider, such as password changes, failed login attempts and administrative privilege usage.
• Deploy robust fraud detection and prevention systems to monitor transactions across multiple channels. As hackers use a multitude of ways to attack bank accounts, a cloud-based solution provides the best coverage.
• Continuously analyze and refine monitoring rules to improve reporting accuracy and reduce any false positives.

4. Focus on Data Protection Measures

The average cost of a data breach was $4.35 million in 2022. It’s crucial for companies to protect sensitive financial and personal data. If hackers sell data on the dark web, it can expose consumers to identity theft and leave companies and government bodies at risk of further attacks.

Action steps:

• Use virtual private networks (VPN) to encrypt sensitive data at all times — especially when sending information online. Getting your remote employees to use VPNs will help prevent hacks on insecure networks.
• Regularly update software and systems to address vulnerabilities. As developers release patches and improve systems, you can reduce the attack surface on your network and applications.
• Implement strict access controls and user permissions to limit data exposure. With these safeguards, it’s easier to protect consumers from hacking threats.

5. Collaborate With Financial Institutions and Law Enforcement

The more companies and security professionals work together with law enforcement and regulatory bodies, the better they will all be able to combat the threat of cyberattacks and financial fraud.

Action steps:

• Join professional networks to share information with other industries and law enforcement agencies. InfraGard is a free-to-join association that connects owners and operators within critical infrastructure industries to the FBI. Through this partnership, companies can provide education and share information on emerging technologies and threats.
• Attend industry conferences to exchange knowledge and best practices. Sending your security team to events like the RSA conference or ACFE Global Fraud Conference gives them the opportunity to build connections with fraud experts from outside of cybersecurity and learn new ways of identifying threats and mitigating fraud.
• Report any suspicious activities, like credit card fraud or tax scams, to the appropriate authorities and collaborate in investigations to learn how best to manage certain types of fraud in the future.

Adopt a hacker mindset to fight financial fraud

Data breaches that leak stolen login user credentials are a significant factor in financial fraud. While human error is hard to account for across millions of users and employees, companies can tighten security controls and improve practices to minimize the risk.

As cyber criminals evolve tactics to seize personal data and compromise financial accounts, security professionals must think like hackers to identify and reduce potential attack vectors. As we develop applications and networks that are secure by design, it becomes easier to thwart attacks and protect users.

The post What to do about the rise of financial fraud appeared first on Security Intelligence.

Hackers stole $4.3 billion worth of cryptocurrency in 2022, making it the worst year on record for crypto fraud. While the government pushes for regulation in the digital coin market, cryptocurrency remains a volatile industry and a risky bet for investors and financial institutions.

While decentralized finance (DeFi) aims to offer greater control to investors, the anonymous nature of banking on the blockchain provides cyber criminals with the smoke and mirrors they need to steal money and vanish without a trace.

But despite the threats, global crypto adoption rates continue to grow — 22% of U.S. adults own cryptocurrency. And so, the onus is on software developers and security teams to step up their efforts to combat cryptocurrency fraud and protect investors. But that’s easier said than done.

How cryptocurrency fraud has grown

Blockchain — the underlying technology behind cryptocurrency — is built on the foundational principles of immutability. The concept is that nobody should be able to steal your money from an encrypted vault. But unfortunately, the reality is an industry riddled with security flaws.

Hackers have a vast arsenal of sophisticated technologies and techniques to infiltrate financial institutions and digital wallets. In its annual Internet Crime Report, the FBI revealed cryptocurrency investment fraud had grown almost three-fold from 2021 to 2022.

Here are five of the most common types of cryptocurrency fraud:

• Ponzi schemes lure unsuspecting victims by making promises of high returns with little or no risk. But when people stop investing, the scheme collapses and the operators take all the money. The CEO of cryptocurrency platform EminiFX, Eddy Alexandre, was charged with running a Ponzi scheme that duped investors out of $59 million.
• Fake wallets and exchanges trick many users into making cryptocurrency transfers. The victims believe they are making a savvy investment but end up downloading malware. Once hackers infiltrate your computer or smartphone, they could access your bank account or steal sensitive personal information to use for other forms of identity theft.
• Fake initial coin offerings (ICOs) work similarly to a Ponzi scheme, as fraudsters create a phony cryptocurrency to attract investors. But once the scammers get enough money, they steal everything. This scheme, known as “pig butchering,” cost a 52-year-old man over $1 million when criminals tricked him into investing in a fraudulent platform.
• Social engineering combines impersonation scams and emotional manipulation to trick people into revealing sensitive information, such as phone numbers, passwords or digital wallet seed phrases. A Coinbase employee fell for an SMS phishing scam in February 2023, enabling a hacker to access the trading platform’s data temporarily.
• Ransomware is commonly used in crypto fraud. Hackers take over a device, account or network using malicious software before demanding payment in cryptocurrency. Although more companies are refusing to pay, ransomware attacks still cost over $456 million in 2022.

Check out the Podcast

What can security teams do to prevent cryptocurrency fraud?

While threat actors are the main problem, many breaches and scams could be prevented with better software development and security practices. Weaknesses in platform security and poorly programmed smart contracts can expose user data and leave companies and consumers vulnerable to attack.

Here are some action steps security teams can take to combat crypto fraud:

1. Verify all users’ identities during onboarding. Onboarding must be flexible enough for new users to join but secure enough to keep fraudsters out.
2. Use strong authentication methods. Multi-factor authentication (MFA) can prevent unauthorized individuals from accessing sensitive information. With stringent demands for biometric factors before high-value transactions, it will be harder for thieves to steal from wallets.
3. Improve privacy with zero-knowledge proofs (ZKP). Using ZKP, you can allow users to prove their identity without revealing personal data, such as their login credentials or social security number.
4. Build a culture of secure network connection protocols. Security teams must do everything possible to protect user data and finances from hackers. Internally, employees must adopt good practices by always using secure devices, HTTPS, password managers and virtual private networks.
5. Invest in robust cybersecurity solutions. At a minimum, teams must fortify online infrastructure with firewalls, antivirus software and 24/7 threat monitoring to safeguard against malware and potential cyberattacks.
6. Monitor platforms with blockchain analysis tools. You can use automated systems to monitor activity on your platform. With a focus on detection and response, security teams can isolate threats or anomalies that might indicate fraud patterns — before the theft happens.
7. Educate users on crypto scams. When people know the warning signs of investment fraud, including romance scams and phishing emails, they’re less likely to fall prey. Security teams and app developers can publish ongoing content about staying safe online, avoiding scams and practicing good cyber hygiene.
8. Offer white-glove fraud resolution support. Hackers only need to get it right once. When the time comes and a user loses to crypto fraud, that’s another opportunity for security teams to learn. Proactive customer support will help users recover from fraud and give teams the information they need to improve their systems.

Keep fraudsters out by securing the inside

Despite the rise in fraud, cryptocurrency continues to attract investors because of the potential for significant returns. But as the global market cap creeps past $1.25 trillion, cyber criminals circle the DeFi space in search of the ultimate payday.

Offering investors education on cryptocurrency scams will help — but the real battle centers on the operations of trading platforms and wallets. It’s time for developers and security teams to unite and play a crucial role in fighting back against cryptocurrency fraud.

Ready to tighten your defenses against hackers? Get a better understanding of the latest attacker tactics by downloading the IBM Security X-Force Threat Intelligence Index 2023.

The post Crypto fraud in 2023: How can security teams fight appeared first on Security Intelligence.