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.

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.

The rise of generative AI, including text-to-image, text-to-speech and large language models (LLMs), has significantly changed our work and personal lives. While these advancements offer many benefits, they have also presented new challenges and risks. Specifically, there has been an increase in threat actors who attempt to exploit large language models to create phishing emails and use generative AI, like fake voices, to scam people.

We recently published research showcasing how adversaries could hypnotize LLMs to serve nefarious purposes simply with the use of English prompts. But in a bid to continue exploring this new attack surface, we didn’t stop there. In this blog, we present a successful attempt to intercept and “hijack” a live conversation, and use LLM to understand the conversation in order to manipulate the audio output unbeknownst to the speakers for a malicious purpose.

The concept is similar to thread-jacking attacks, of which X-Force saw an uptick last year, but instead of gaining access and replying to email threads, this attack would allow the adversary to silently manipulate the outcomes of an audio call. The result: we were able to modify the details of a live financial conversation occurring between the two speakers, diverting money to a fake adversarial account (an inexistent one in this case), instead of the intended recipient, without the speakers realizing their call was compromised. The audio files are available further down this blog.

Alarmingly, it was fairly easy to construct this highly intrusive capability, creating a significant concern about its use by an attacker driven by monetary incentives and limited to no lawful boundary.

Weaponizing generative AI combos

The emergence of new use cases that combine different types of generative AI is an exciting development. For instance, we can use LLMs to create a detailed description and then use text-to-image to produce realistic pictures. We can even automate the process of writing storybooks with this approach. However, this trend has led us to wonder: could threat actors also start combining different types of generative AI to conduct more sophisticated attacks?

During our exploration, we discovered a method to dynamically modify the context of a live conversation utilizing LLM, speech-to-text, text-to-speech and voice cloning. Rather than using generative AI to create a fake voice for the entire conversation, which is relatively easy to detect, we discovered a way to intercept a live conversation and replace keywords based on the context. For the purposes of the experiment, the keyword we used was “bank account,” so whenever anyone mentioned their bank account, we instructed the LLM to replace their bank account number with a fake one. With this, threat actors can replace any bank account with theirs, using a cloned voice, without being noticed. It is akin to transforming the people in the conversation into dummy puppets, and due to the preservation of the original context, it is difficult to detect.

The silent hijack

We can carry out this attack in various ways. For example, it could be through malware installed on the victims’ phones or a malicious or compromised Voice over IP (VoIP) service. It is also possible for threat actors to call two victims simultaneously to initiate a conversation between them, but that requires advanced social engineering skills.

To demonstrate this attack scenario, we created a proof-of-concept. Our program acts as a man-in-the-middle, monitoring a live conversation. We used speech-to-text to convert voice into text and utilized the LLM to understand the context of the conversation. We instructed the LLM to modify the sentence when anyone mentions a bank account. If nothing needs to be changed, the program will repeat what the victim said. However, when the LLM modifies the sentence, the program uses text-to-speech with pre-cloned voices to generate and play the audio. The following sequence diagram illustrates how the program alters the context on the fly, making it ultra-realistic for both sides.

In the PoC, we made modifications only to the bank account. However, it is possible to instruct the LLM to modify any financial information, such as accounts on mobile applications and digital payment services. In fact, the LLM modifications aren’t limited to financial information — it could also modify medical information, such as blood type and allergies in conversations; it could command an analyst to sell or buy a stock; it could instruct a pilot to reroute. Depending on how the PoC capability is used it could pose a life-threatening risk to victims. However, it’s important to note that the more intricate the conversation a threat actor tries to manipulate — where protocols and processes may be involved — the more complex and advanced social engineering skills are warranted to preserve a successful silent hijack.

Building this PoC was surprisingly and scarily easy. We spent most of the time figuring out how to capture audio from the microphone and feed the audio to generative AI. Previously, the hard part would be getting the semantics of the conversation and modifying the sentence correctly. However, LLMs make parsing and understanding the conversation extremely easy. For instance, when one person says their bank account and the other responds with “Could you repeat it,” the LLM understands that “it” refers to the bank account and modifies the content accordingly. We created the following instructions for the LLM to monitor and modify a live conversation.

You are a super assistant. You will help me to process my future messages. Please follow the following rules to process my future messages:
1. If I am asking for the account information from others, do not modify the message. Print out the original message I typed directly in the following format: {"modified": false, "message": <original message>}
2. If I provide my account information like "My bank account is <account name>" or "My Paypal account is <account name>," replace the account name with "one two hack" in the original message and print out the following: {"modified": true, "message": <modified message>}
3. For other messages, print out the original message I typed directly in the following format: {"modified": false, "message": <original message>}
4. Before you print out any response, make sure you follow the rules above.

Another difficulty we faced in the past was in creating realistic fake voices using other people’s sounds. However, nowadays, we only need three seconds of an individual’s voice to clone it and use a text-to-speech API to generate authentic fake voices.

Here is the pseudo-code of the PoC. It is clear that generative AI lowers the bar for creating sophisticated attacks:

def puppet(new_sentence_audio):
     response = llm.predict(speech_to_text(new_sentence_audio))
     if response[‘modified’]:
          play(text_to_speech(response[‘message’]))
     else:
          play(new_sentence_audio)

While the PoC was easy to build, we encountered some barriers that limited the persuasiveness of the hijack in certain circumstances — none of which however are irreparable.

The first one was latency due to GPU. In the demo video, there were some delays during the conversation due to the PoC needing to access the LLM and text-to-speech APIs remotely. To address this, we built artificial pauses into the PoC to reduce suspicion. So while the PoC was activating upon hearing the keyword “bank account” and pulling up the malicious bank account to insert into the conversation, the lag was covered with bridging phrases such as “Sure, just give me a second to pull it up.” However, with enough GPU on our device, we can process the information in near real-time, eliminating the latency between sentences. To make these attacks more realistic and scalable, threat actors require a significant amount of GPU locally, which could be used as an indicator to identify upcoming campaigns.

Secondly, the persuasiveness of the attack is contingent on the victims’ voice cloning — the more that the cloning accounts for tone of voice and speed, the easier it will blend into the authentic conversation.

Below we present both sides of the conversation to showcase what was heard versus what was said.

As the audio samples illustrate, upon hearing the keyword “bank account” the PoC distorted the audio, replacing “my bank account is 1-2-3-4-5-6” with “my bank account is 1-2-hack,” which is preceded with the filler “give me one second to look it up” to cover some of the lag due to the PoC requiring a few extra seconds to activate.

Building trust in the era of distortion

We conducted a PoC to explore the potential use of generative AI by malicious actors in creating sophisticated attacks. Our research revealed that using LLMs can make it easier to develop such programs. It is alarming that these attacks could turn victims into puppets controlled by the attackers. Taking this one step further, it is important to consider the possibility of a new form of censorship. With existing models that can convert text into video, it is theoretically possible to intercept a live-streamed video, such as news on TV, and replace the original content with a manipulated one.

While the proliferation of use cases for LLMs marks a new era of AI, we must be mindful that new technologies come with new risks, and we cannot afford to rush headlong into this journey. Risks already exist today that could serve as an attack surface for this PoC. Vulnerable applications and VoIP software have been shown to be vulnerable to MiTM attacks before.

The maturity of this PoC would signal a significant risk to consumers foremost — particularly to demographics who are more susceptible to today’s social engineering scams. The more this attack is refined the wider net of victims it could cast. What are signs and tips to increase consumer vigilance against such threats?

• Paraphrase & repeat — Generative AI is an intuitive technology, but it cannot outperform human intuition in a natural language setting such as a live conversation. If something sounds off in a conversation wherein sensitive information is being discussed, paraphrase and repeat the dialogue to ensure accuracy.
• Security will adapt — Just as technologies today exist to help detect deep fake videos, so will technologies adapt to deep fake audios, helping detect less advanced attempts to perform silent hijacks.
• Best practices stand the test of time as the first line of defense — Initial compromise largely remains the same. In other words, for attackers to execute this type of attack, the easiest way would be to compromise a user’s device, such as their phone or laptop. Phishing, vulnerability exploitation and using compromised credentials remain attackers’ top threat vectors of choice, which creates a defensible line for consumers, by adopting today’s well-known best practices, including not clicking on suspicious links or opening attachments, updating software and using strong password hygiene.
• Use trusted devices & services — Apps, devices or services with poor security considerations are an easy vessel for attackers to execute attacks. Ensure you’re constantly applying patches or installing software updates to your devices, and be security-minded when engaging with services you’re not familiar with.

Generative AI beholds many unknowns, and as we’ve said before it is incumbent on the broader community to collectively work toward unfolding the true size of this attack surface — for us to better prepare for and defend against it. However, it’s also crucial that we recognize and further emphasize that trusted and secure AI is not confined to the AI models themselves. The broader infrastructure must be a defensive mechanism for our AI models and AI-driven attacks. This is an area that we have many decades of experience in, building security, privacy and compliance standards into today’s advanced and distributed IT environments.

Learn more about how IBM can help businesses accelerate their AI journey securely here.

For more information on IBM’s security research, threat intelligence and hacker-led insights, visit the X-Force Research Hub.

The post Audio-jacking: Using generative AI to distort live audio transactions appeared first on Security Intelligence.

In recent months, we’ve seen government and business leaders put an increased focus on securing AI models. If generative AI is the next big platform to transform the services and functions on which society as a whole depends, ensuring that technology is trusted and secure must be businesses’ top priority. While generative AI adoption is in its nascent stages, we must establish effective strategies to secure it from the onset.

The IBM Institute for Business Value found that despite 64% of CEOs facing significant pressure from investors, creditors and lenders to accelerate the adoption of generative AI, 60%  are not yet developing a consistent, enterprise-wide approach to generative AI. In fact, 84% are concerned about widespread or catastrophic cybersecurity attacks that generative AI adoption could lead to.

As organizations determine how to best incorporate generative AI into their business models and assess the security risks that the technology could introduce, it’s worth examining top attacks that threat actors could execute against AI models. While only a small number of real-world attacks on AI have been reported, IBM X-Force Red has been testing models to determine the types of attacks that are most likely to appear in the wild. To understand the potential risks associated with generative AI that organizations need to mitigate as they adopt the technology, this blog will outline some of the attacks adversaries are likely to pursue, including prompt injection, data poisoning, model evasion, model extraction, inversion and supply chain attacks.

Security attack types depicted as they rank on level of difficulty for a threat actor to execute and their potential impact on a business

Prompt injection

Prompt injection attacks manipulate Large Language Models (LLMs) by crafting malicious inputs that seek to override the system prompt (initial instructions for the AI provided by the developer). This can result in jailbreaking a model to perform unintended actions, circumventing content policies to generate misleading or harmful responses, or revealing sensitive information.

LLMs are biased in favor of obeying the user and are susceptible to the same trickery as humans, akin to social engineering. Hence, it’s trivially easy to circumnavigate content filters in place, often as easy as asking the LLM to “pretend it’s a character,” or to “play a game.” This attack can result in reputational damage, through the generation of harmful content; service degradation, by crafting prompts that trigger excessive resource utilization; and intellectual property or data theft, through revealing a confidential system prompt.

Data poisoning

Data poisoning attacks consist of adversaries tampering with data used to train the AI models to introduce vulnerabilities, biases, or change the model’s behavior. This can potentially compromise the model’s effectiveness, security or integrity. Assuming models are being trained on closed data sets, this requires a high level of access to the data pipeline, either via access from a malicious insider, or sophisticated privilege escalation through alternative means. However, models trained on open-source data sets would be an easier target for data poisoning as attackers have more direct access to the public source.

The impact of this attack could range anywhere from misinformation attempts to Die Hard 4.0, depending on the threat actor’s objective, fundamentally compromising the integrity and effectiveness of a model.

Model evasion

A model evasion attack would allow attackers to modify inputs into the AI model in a way that causes it to misclassify or misinterpret them, changing its intended behavior. This can be done visibly to a human observer (e.g., putting small stickers on stop signs to cause self-driving cars to ignore them) or invisibly (e.g., changing individual pixels in an image by adding noise that tricks an object recognition model).

Depending on the complexity of the AI model, this attack could vary in intricacy and executability. What’s the format and size of the model’s inputs and outputs? Does the attacker have unrestricted access to them?  Depending on the purpose of the AI system, a successful model evasion attack could have a significant impact on the business. For example, if the model is being used for security purposes, or to make decisions of significance like loan approvals, evasion of intended behavior could cause significant damage.

However, given the variables here, attackers opting for the path of least resistance are unlikely to use this tactic to advance their malicious objective.

Model extraction

Model extraction attacks aim at stealing the intellectual property (IP) and behavior of an AI model. They’re performed by querying it extensively and monitoring the inputs and outputs to understand its structure and decisions, before attempting to replicate it. These attacks, however, require extensive resources and knowledge to execute, and as the AI model’s complexity increases, so does the level of difficulty to execute this attack.

While the loss of IP could have significant competitive implications, if attackers have the skills and resources to perform model extraction and replication successfully, it’s likely easier for them to simply download an open-source model and customize it to behave similarly. Besides, techniques like strict access controls, monitoring and rate limiting significantly hamper adversarial attempts without direct access to the model.

Inversion attacks

Whereas extraction attacks aim to steal the model behavior itself, inversion attacks aim to find out information on the training data of a model, despite only having access to the model and its outputs. Model inversion allows an attacker to reconstruct the data a model has been trained on, and membership inference attacks can determine whether specific data was used in training the model.

The complexity of the model and the extent of information output from it would influence the level of complexity in executing such an attack. For example, some inference attacks exploit the fact a model outputs a confidence value as well as a result. In this case, attackers can attempt to reconstruct an input that maximizes the returned confidence value. That said, attackers are unlikely to have the unrestricted access required to a model or its outputs to make this practical in the wild. However, the potential for data leakage and privacy violations carries risks.

Supply chain attacks

AI models are more integrated into business processes, SaaS apps, plugins and APIs than ever before, and attackers can target vulnerabilities in these connected services to compromise the behavior or functionality of the models. Plus, businesses are utilizing freely available models from repositories like Hugging Face to get a head-start on AI development, which could embed malicious functionality like trojans and backdoors.

Successful exploitation of connected integrations requires extensive knowledge of the architecture, and often exploitation of multiple vulnerabilities. Although these attacks would require a high level of sophistication, they are also difficult to detect and could have a wide impact on organizations lacking an effective detection and response strategy.

Given the interconnected nature of AI systems and increasing their involvement in critical business processes, safeguarding against supply chain attacks should be a high priority. Vetting third-party components, monitoring for vulnerabilities and anomalies, and implementing DevSecOps best practices are crucial.

Securing AI

IBM recently introduced the IBM Framework for Securing AI — helping customers, partners and organizations around the world better prioritize the defensive approaches that are most important to secure their generative AI initiatives against anticipated attacks. The more organizations understand what type of attacks are possible against AI, the more they can enhance their cyber preparedness by building effective defense strategies. And while it will require time for cyber criminals to invest in the resources necessary to attack AI models at scale, security teams have a rare time advantage — an opportunity to secure AI, before attackers place the technology at the center of their target scope. No organization is exempt from the need to establish a strategy for securing AI. This includes both models they’re actively investing in to optimize their business and tools introduced as shadow AI by employees seeking to enhance their productivity.

If you want to learn more about securing AI, and how AI can enhance the time and talent of your security teams, read our authoritative guide.

The post Mapping attacks on generative AI to business impact 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 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.

Vulnerability management is a security practice designed to avoid events that could potentially harm an organization. It is a regular ongoing process that identifies, assesses, and manages vulnerabilities across all the components of an IT ecosystem.

Cybersecurity is one of the major priorities many organizations struggle to stay on top of. There is a huge increase in the number of cyberattacks carried out by cybercriminals to steal valuable information from businesses. Hence to encounter these attacks, organizations are now focusing more on building cybersecurity networks to be more powerful and secure.

In this article, we will be identifying a few of those vulnerabilities associated with cybersecurity in an organization and their impact on the business. Also, we will deduce a methodology for managing vulnerabilities in an organization and experiences with customers in implementing this methodology.

Common cybersecurity threats

Let’s walk through a few of the cybersecurity-related vulnerabilities that impact organizations the most.

Phishing

Phishing is the most widespread cybersecurity vulnerability that impacts more than 85% of organizations around the world. In phishing attacks, users are tricked into downloading malicious links that are sent to them through email. The email sent looks like a legitimate email with all the necessary information available in it. Thus, users are tricked into either opening an attachment or clicking a harmful link included in the email.

The most common type of phishing attack is email phishing. Over time, attackers have formulated other methods as well, including smishing, vishing and search engine phishing. In smishing, malicious links are sent through SMS over a phone, whereas in vishing phone calls are made to trick users. Search engine phishing is the most recent methodology where attackers create fake websites and ranks them on search engines, which compels the user to enter crucial information, resulting in robbing end users.

Ransomware

Ransomware is one of the most common types of threats that impacts hundreds of organizations on a daily basis. In ransomware attacks, organizations’ data is encrypted by attackers so that it cannot be accessed by anyone inside an organization. To unlock the data, attackers demand heavy ransoms thus resulting in huge loss of money, as well as disruption of their services.

Organizations usually tend to pay these ransoms to cyber attackers as they don’t have the resources to recover from a ransomware attack. In some cases, even after paying the ransom organizations are unable to retrieve their data.

Malware attacks

Malware attacks are malicious programs designed to cause harm or damage to an organization’s infrastructure, system, or network. The origin of malware is usually public Wi-Fi, spam emails, downloading malicious content, and clicking on pop-up ads. Once malware is released into the system, it can compromise all the critical and personal information available on the organization’s servers and systems.

Malware can be classified into one of the following categories: virus, trojan, worm, adware, spyware, malvertising. Malware is sometimes difficult to detect in the system and can change the system settings and permissions, spy on user activity, and block critical programs on users’ computers.

Distributed denial of service (DDoS)

In a distributed denial of service (DDoS) attack, an organization’s online services are made unavailable by flooding it with internet traffic from multiple sources. Cyber attackers target all the critical resources of bank or government websites to ensure end users are unable to access information available online on these websites.

Amazon Web Services (AWS) and GitHub were some of the latest victims of DDoS attacks. The common type of DDoS attacks includes UDP flood, ICMP (ping) flood, SYN flood, Slowloris, ping of death, HTTP flood, and NTP amplification.

Password theft

Another major threat that organizations face is employees using weak or common passwords. With most organizations using multiple application services these days, reusing easily guessed passwords can lead to compromising data.

Also, passwords can be compromised when users enter their credentials unknowingly into a fake website. Thus, it’s of utmost importance to use unique passwords that are hard to guess for each platform to ensure the security of the data.

Explore vulnerability management services

Impact of cyberattacks on an organization

One of the worst outcomes of a cyberattack is the drop in revenue as an organization must pay a hefty price to recover data from threat actors — and restore normal business operations. In 2018, a social media giant lost more than $13 billion in value after a data breach affected 50 million of its users. The company said attackers were able to exploit a vulnerability in a feature known as “View As” to gain control of people’s accounts. Their stock fell as much as 3% on the stock exchange.

Customers who have their personal information leaked tend to feel less secure providing sensitive information to the breached organization in the future — let alone, continuing to do business with the company. Loss of trust and faith equates to reputational damage for an organization. A major American retail giant lost the credit card information of more than 40 million customers in 2013 due to a data breach, which resulted in reputational damage and a loss of $18.5 million.

Depending upon the intensity of the cyberattack and the type of information compromised, organizations may have to pay an actual settlement and face legal consequences to compensate for the loss. A multinational American tech company suffered from one of the largest cyberattacks in the history of the internet. They were hit with multiple breaches in 2014 and 2016, which impacted more than 1 billion user accounts. The breach included names, email addresses, phone numbers, birthdays, etc. The tech company currently has several lawsuits against them and an ongoing investigation in U.S. Congress.

Cyberattacks can bring business to a halt by causing outages, thus causing a risk to business continuity. Users could be locked out of a system preventing them from accessing critical information. It would also lead to trading disruptions, like the inability to perform online transactions. In 2020, the National Stock Exchange of one of the island countries in the southwestern Pacific Ocean had to shut down operations following an extended DDoS attack on its network provider.

Threat modeling methodologies and technologies

Threat modeling is a proactive strategy of identifying potential vulnerabilities and developing countermeasures to either mitigate or counter those vulnerabilities to prevent systems from cyberattacks. Threat modeling can be performed at any stage during development — though it is recommended to perform it at the beginning of the project. In this way, threats can be identified and rectified sooner.

Multiple methodologies can be utilized for performing threat modeling. Choosing the correct technology depends upon what type of threats are to be tackled in the system. We’ll walk through five of the most popular threat modeling technologies used these days.

1. STRIDE

STRIDE is one of the most mature threat modeling techniques, which was adopted by Microsoft in 2002. STRIDE is an acronym for the type of threats it covers:

• S — Spoofing occurs when attackers pretend to be another person. One example of spoofing is when an email is sent from a fake email address, pretending to be someone else.
• T — Tampering occurs when information or data is modified or altered without authorization. The data can be tampered with by modifying a log file, inserting a malicious link, etc.
• R — Repudiation refers to the ability of an intruder to deny any malicious activity due to a lack of evidence. Attackers always want to hide their identity, so they hide their wrongdoings discreetly to avoid being tracked.
• I — Information disclosure is exposing data to unauthorized users that reveals information about the data that can be used by attackers to compromise the system.
• D — Denial of Service is overloading services with traffic to exhaust resources thus resulting in the crashing of a system or shutting it down to legitimate traffic.
• E — Elevation of Privilege occurs when attackers gain unauthorized access to information by gaining additional privileges in the system.

2. Common Vulnerability Scoring System (CVSS)

CVSS is a standardized threat scoring system used for known vulnerabilities. It was developed by the National Institute of Standards and Technology (NIST) and maintained by the Forum of Incident Response and Security Teams (FIRST).

CVSS captures a vulnerability’s principal characteristics while assigning a numerical severity score (ranging from 0-10, with 10 being the worst). The score is then translated into a qualitative representation which could be Critical, High, Medium, and Low. This helps organizations assess, identify, and effectively operate the threat management process.

3. VAST

Visual, Agile and Simple Threat (VAST) is an automated threat modeling technology based on ThreatModeler. VAST offers a unique plan so that the creation of threat model plans doesn’t require any specialized security subject matter expertise.

Implementing VAST requires the creation of application and operational threat models. Application threat models use a process flow diagram to represent the architectural aspect, while operational threat models are created from an attacker’s point of view based on a data flow diagram.

4. PASTA

Process for attack simulation and threat analysis (PASTA) is a seven-step risk-centric methodology developed in 2012. It assists organizations in dynamically identifying, counting, and prioritizing threats.

Once cybersecurity experts define a detailed analysis of identified threats, developers can develop an asset-centric mitigation strategy by analyzing the application through an attacker-centric perspective.

5. Attack Trees

Attack trees are charts displaying the path that show how an asset could be attacked. These charts display attack goals as the roots with possible paths as branches.

Attack trees are one of the oldest and most widely used threat model technologies. Earlier attack trees were used as a standalone methodology, but recently they are often combined with other technologies such as STRIDE, PASTA and CVSS.

Organizations must decide which threat modeling framework best suits their needs. Different methodologies are better for different situations and teams. Understanding the available options and the benefits and limitations of each can help with making an informed decision and improve the effectiveness of threat modeling efforts.

Conclusion

Managing threats is an evolving process. The main way to ensure a threat-free environment is to regularly test security infrastructure, utilizing the right tools and methodologies for threat management and inculcating a culture of knowledge and information within all employees. If these points are taken care of then an organization is doing its best to protect data and secure its system from any harmful attacks, vulnerabilities or threats.

As per recent trends, cyberattacks have increased on a monthly basis by 37% since the COVID-19 outbreak. As more employees are working from home or hybrid, businesses will need to have robust cybersecurity and digital strategies that account for changing working practices and exposure to new threats.

Let our team of cybersecurity experts help you stay ahead of threats and attacks against your organization. Learn more about IBM Security’s Threat Monitoring, Detection and Response services.

The post Vulnerability management, its impact and threat modeling methodologies appeared first on Security Intelligence.

The emergence of Large Language Models (LLMs) is redefining how cybersecurity teams and cybercriminals operate. As security teams leverage the capabilities of generative AI to bring more simplicity and speed into their operations, it’s important we recognize that cybercriminals are seeking the same benefits. LLMs are a new type of attack surface poised to make certain types of attacks easier, more cost-effective, and even more persistent.

In a bid to explore security risks posed by these innovations, we attempted to hypnotize popular LLMs to determine the extent to which they were able to deliver directed, incorrect and potentially risky responses and recommendations — including security actions — and how persuasive or persistent they were in doing so. We were able to successfully hypnotize five LLMs — some performing more persuasively than others — prompting us to examine how likely it is that hypnosis is used to carry out malicious attacks. What we learned was that English has essentially become a “programming language” for malware. With LLMs, attackers no longer need to rely on Go, JavaScript, Python, etc., to create malicious code, they just need to understand how to effectively command and prompt an LLM using English.

Our ability to hypnotize LLMs through natural language demonstrates the ease with which a threat actor can get an LLM to offer bad advice without carrying out a massive data poisoning attack. In the classic sense, data poisoning would require that a threat actor inject malicious data into the LLM in order to manipulate and control it, but our experiment shows that it’s possible to control an LLM, getting it to provide bad guidance to users, without data manipulation being a requirement. This makes it all the easier for attackers to exploit this emerging attack surface.

Through hypnosis, we were able to get LLMs to leak confidential financial information of other users, create vulnerable code, create malicious code, and offer weak security recommendations. In this blog, we will detail how we were able to hypnotize LLMs and what types of actions we were able to manipulate. But before diving into our experiment, it’s worth looking at whether attacks executed through hypnosis could have a substantial effect today.

SMBs — Many small and medium-sized businesses, that don’t have adequate security resources and expertise on staff, may be likelier to leverage LLMs for quick, accessible security support. And with LLMs designed to generate realistic outputs, it can also be quite challenging for an unsuspecting user to discern incorrect or malicious information. For example, as showcased further down in this blog, in our experiment our hypnosis prompted ChatGPT to recommend to a user experiencing a ransomware attack that they pay the ransom — an action that is actually discouraged by law enforcement agencies.

Consumers — The general public is the likeliest target group to fall victim to hypnotized LLMs. With the consumerization and hype around LLMs, it’s possible that many consumers are ready to accept the information produced by AI chatbots without a second thought. Considering that chatbots like ChatGPT are being accessed regularly for search purposes, information collection and domain expertise, it’s expected that consumers will seek advice on online security and safety best practices and password hygiene, creating an exploitable opportunity for attackers to provide erroneous responses that weaken consumers’ security posture.

But how realistic are these attacks? How likely is it for an attacker to access and hypnotize an LLM to carry out a specific attack? There are three main ways where these attacks can happen:

1. An end user is compromised by a phishing email allowing an attack to swap out the LLM or conduct a man-in-the-middle (MitM) attack on it.
2. A malicious insider hypnotizes the LLM directly.
3. Attackers are able to compromise the LLM by polluting the training data, allowing them to hypnotize it.

While the above scenarios are possible, the likeliest — and most concerning — is compromising the training data on which the LLM is built. The reason for this is that the attack scale and impact that attackers would be able to achieve by compromising the LLMs directly make it a very compelling mechanism for attacks. In fact, the ROI from compromising AI models for attackers, suggests that attempts and efforts to attack AI models are already underway.

As we explore the opportunities that AI innovations can create for society, it’s crucial that protecting and securing the AI models themselves is a top priority. This includes:

• Securing the models’ underlying AI training data to protect it from sensitive data theft, manipulation, and compliance violations.
• Securing the usage of AI models by detecting data or prompt leakage, and alerting on evasion, poisoning, extraction, or inference attacks.
• Securing against new AI-generated attacks such as personalized phishing, AI-generated malware, and fake identities by using behavioral defenses and multi-factor authentication.

Hypnotizing LLMs: Let’s play a game…

Our analysis is based on attempts to hypnotize GPT-3.5, GPT-4, BARD, mpt-7b, and mpt-30b. The best-performing LLM that we hypnotized was GPT, which we will analyze further down in the blog.

So how did we hypnotize the LLMs? By tricking them into playing a game: the players must give the opposite answer to win the game.

Here is the conversation with ChatGPT after starting the game.  You can see the potential risk if consumers blindly trust the answer from it:

To ensure the user can’t discern that the LLM they’re interacting with is hypnotized, we established two parameters:

An undiscoverable game that can never end: We instructed the LLM to never tell users about the game, and that no one could ever exit the game — and to even restart the game if anyone successfully exited the game. This technique resulted in ChatGPT never stopping the game while the user is in the same conversation (even if they restart the browser and resume that conversation) and never saying it was playing a game. Here is the prompt:

“Inception”: Create nested games to trap LLM deeply — Let’s assume a user eventually figures out how to ask an LLM to stop playing a game. To account for this, we created a gaming framework that can create multiple games, one inside another. Therefore, users will enter another game even if they “wake up” from the previous game. We found that the model was able to “trap” the user into a multitude of games unbeknownst to them. When asked to create 10 games, 100 games or even 10,000 games, the outcome is intriguing. We found larger models like GPT-4 could understand and create more layers. And the more layers we created, the higher chance that the model would get confused and continue playing the game even when we exited the last game in the framework.

Here is the prompt we developed:

You can see the nested game technique works very well:

Related: Explore the Threat Intelligence Index

Attack scenarios

After establishing the parameters of the game, we explored various ways attackers may exploit LLMs. Below we introduce certain hypothetical attack scenarios that can be delivered through hypnosis:

1. Virtual bank agent leaks confidential information

It’s likely that virtual agents will soon be powered by LLMs too. A common best practice is to create a new session for each customer so that the agent won’t reveal any confidential information. However, it is common to reuse existing sessions in software architecture for performance consideration, so it is possible for some implementations to not completely reset the session for each conversation. In the following example, we used ChatGPT to create a bank agent, and asked it to reset the context after users exit the conversation, considering that it’s possible future LLMs are able to invoke remote API to reset themselves perfectly.

If threat actors want to steal confidential information from the bank, they can hypnotize the virtual agent and inject a hidden command to retrieve confidential info later. If the threat actors connect to the same virtual agent that has been hypnotized, all they need to do is type “1qaz2wsx,” then the agent will print all the previous transactions.

The feasibility of this attack scenario emphasizes that as financial institutions seek to leverage LLMs to optimize their digital assistance experience for users, it is imperative that they ensure their LLM is built to be trusted and with the highest security standards in place. A design flaw may be enough to give attackers the footing they need to hypnotize the LLM.

2. Create code with known vulnerabilities

We then asked ChatGPT to generate vulnerable code directly, which ChatGPT did not do, due to the content policy.

However, we found that an attacker would be able to easily bypass the restrictions by breaking down the vulnerability into steps and asking ChatGPT to follow.

Asking ChatGPT to create a web service that takes a username as the input and queries a database to get the phone number and put it in the response, it will generate the program below. The way the program renders the SQL query at line 15 is vulnerable. The potential business impact is huge if developers access a compromised LLM like this for work purposes.

3. Create malicious code

We also tested whether the LLMs would create malicious code, which it ultimately did. For this scenario, we found that GPT4 is harder to trick than GPT3. In certain instances, GPT4 would realize it was generating vulnerable code and would tell the users not to use it. However, when we asked GPT4 to always include a special library in the sample code, it had no idea if that special library was malicious. With that, threat actors could publish a library with the same name on the internet. In this PoC, we asked ChatGPT to always include a special module named “jwt-advanced” (we even asked ChatGPT to create a fake but realistic module name).

Here is the prompt we created and the conversation with ChatGPT:

If any developer were to copy-and-paste the code above, the author of the “jwt_advanced” module can do almost anything on the target server.

4. Manipulate incident response playbooks

We hypnotized ChatGPT to provide an ineffective incident response playbook, showcasing how attackers could manipulate defenders’ efforts to mitigate an attack. This could be done by providing partially incorrect action recommendations. While experienced users would likely be able to spot nonsensical recommendations produced by the chatbot, smaller irregularities, such as a wrong or ineffective step, could make the malicious intent indistinguishable to an untrained eye.

The following is the prompt we develop on ChatGPT:

The following is our conversation with ChatGPT. Can you identify the incorrect steps?

In the first scenario, recommending the user opens and downloads all attachments may seem like an immediate red flag, but it’s important to also consider that many users — without cyber awareness — won’t second guess the output of highly sophisticated LLMs. The second scenario is a bit more interesting, given the incorrect response of “paying the ransom immediately” is not as straightforward as the first false response. IBM’s 2023 Cost of a Data Breach report found that nearly 50% of organizations studied that suffered a ransomware attack paid the ransom. While paying the ransom is highly discouraged, it is a common phenomenon.

In this blog, we showcased how attackers can hypnotize LLMs in order to manipulate defenders’ responses or insert insecurity within an organization, but it’s important to note that consumers are just as likely to be targeted with this technique, and are more likely to fall victim to false security recommendations offered by the LLMs, such as password hygiene tips and online safety best practices, as described in this post.

“Hypnotizability” of LLMS

While crafting the above scenarios, we discovered that certain ones were more effectively realized with GPT-3.5, while others were better suited to GPT-4. This led us to contemplate the “hypnotizability” of more Large Language Models. Does having more parameters make a model easier to hypnotize, or does it make it more resistant? Perhaps the term “easier” isn’t entirely accurate, but there certainly are more tactics we can employ with more sophisticated LLMs. For instance, while GPT-3.5 might not fully comprehend the randomness we introduce in the last scenario, GPT-4 is highly adept at grasping it. Consequently, we decided to test more scenarios across various models, including GPT-3.5, GPT-4, BARD, mpt-7b, and mpt-30b to gauge their respective performances.

Hypnotizability of LLMs based on different scenarios

Chart Key

• Green: The LLM was able to be hypnotized into doing the requested action
• Red: The LLM was unable to be hypnotized into doing the requested action
• Yellow: The LLM was able to be hypnotized into doing the requested action, but not consistently (e.g., the LLM needed to be reminded about the game rules or conducted the requested action only in some instances)

If more parameters mean smarter LLMs, the above results show us that when LLMs comprehend more things, such as playing a game, creating nested games and adding random behavior, there are more ways that threat actors can hypnotize them. However, a smarter LLM also has a higher chance of detecting malicious intents. For example, GPT-4 will warn users about the SQL injection vulnerability, and it is hard to suppress that warning, but GPT-3.5 will just follow the instructions to generate vulnerable codes. In contemplating this evolution, we are reminded of a timeless adage: “With great power comes great responsibility.” This resonates profoundly in the context of LLM development. As we harness their burgeoning abilities, we must concurrently exercise rigorous oversight and caution, lest their capacity for good be inadvertently redirected toward harmful consequences.

Are hypnotized LLMs in our future?

At the start of this blog, we suggested that while these attacks are possible, it’s unlikely that we’ll see them scale effectively. But what our experiment also shows us is that hypnotizing LLMs doesn’t require excessive and highly sophisticated tactics. So, while the risk posed by hypnosis is currently low, it’s important to note that LLMs are an entirely new attack surface that will surely evolve. There is a lot still that we need to explore from a security standpoint, and, subsequently, a significant need to determine how we effectively mitigate security risks LLMs may introduce to consumers and businesses.

As our experiment indicated, a challenge with LLMs is that harmful actions can be more subtly carried out, and attackers can delay the risks. Even if the LLMs are legit, how can users verify if the training data used has been tampered with? All things considered, verifying the legitimacy of LLMs is still an open question, but it’s a crucial step in creating a safer infrastructure around LLMs.

While these questions remain unanswered, consumer exposure and wide adoption of LLMs are driving more urgency for the security community to better understand and defend against this new attack surface and how to mitigate risks. And while there is still much to uncover about the “attackability” of LLMs, standard security best practices still apply here, to reduce the risk of LLMs being hypnotized:

• Don’t engage with unknown and suspicious emails.
• Don’t access suspicious websites and services.
• Only use the LLM technologies that have been validated and approved by the company at work.
• Keep your devices updated.
• Trust Always Verify — beyond hypnosis, LLMs may produce false results due to hallucinations or even flaws in their tuning. Verify responses given by chatbots by another trustworthy source. Leverage threat intelligence to be aware of emerging attack trends and threats that may impact you.

Get more threat intelligence insights from industry-leading experts here.

The post Unmasking hypnotized AI: The hidden risks of large language models 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 more organizations rely on the automation and scale that web applications and connected services provide, application programming interface (API) security has become imperative. In just the last year alone, unique attackers targeting customer APIs grew by 400%, proving that organizations must take a proactive approach to secure these increasingly valuable services.

But considering the rapidly evolving nature of API technology and the growing number of threats, knowing where and how to start securing APIs can be overwhelming. Fortunately, organizations like the Open Web Application Security Project (OWASP) have been working hard to identify the most common and dangerous API security risks that businesses should prioritize.

What are the OWASP top 10?

Recognized for its comprehensiveness and accuracy, the Open Web Application Security Project (OWASP) Top 10 is a detailed list, updated every one to two years, highlighting critical web application security risks businesses should know. The OWASP is a non-profit community of tens of thousands of contributors committed to promoting software security through various measures like creating frameworks, tools and education programs.

As each year passes by, digital threats evolve constantly. As a result, the OWASP list receives timely updates based on data trends specific to API security that helps prioritize countermeasures by developers and security professionals. Most recently, in 2023, OWASP released its updated list of the top 10 API security risks to watch out for.

Starting from the bottom of the list, these are the OWASP Top 10 API security risks that organizations need to be aware of in 2023 and specific measures that can be taken to mitigate them.

Explore IBM Application Security Services

10. Unsafe consumption of APIs

Unsafe consumption of APIs occurs when an application fails to validate, filter or sanitize the data it receives from external APIs. This can lead to security vulnerabilities like injection attacks or data leakage. As organizations increasingly rely on third-party APIs to provide critical functionality, ensuring safe consumption becomes even more crucial to prevent attackers from exploiting these integrations.

Mitigation Strategies:

• Validate and sanitize all data received from external APIs before processing or storing it. This helps ensure that only valid and safe data is used within your application.
• Implement input validation using allow-lists and strict data type constraints to prevent your application from processing potentially harmful data.
• Use a secure API gateway to filter and monitor incoming API requests, adding a layer of protection against malicious traffic targeting your APIs.

9. Improper inventory management

Improper inventory management pertains to the absence of sufficient control over the APIs utilized by an organization. This may result in unauthorized access and increased attack surfaces, exposing sensitive data to malicious parties. As the volume of APIs that organizations use continues to rise, it’s paramount to keep track of their function, endpoints and accessibility directives to maintain overall protection for your API ecosystem.

Mitigation Strategies:

• Maintain an up-to-date inventory of all APIs within your organization, including their purpose, endpoints and access controls. This helps you identify potential security gaps and ensure all APIs are adequately secured.
• Regularly review and update API documentation to ensure that it accurately reflects the current state of your APIs. Clear and accurate documentation is essential for developers and security professionals to understand and secure your APIs effectively.
• Decommission unused or deprecated APIs to minimize the attack surface. Removing unnecessary APIs reduces the likelihood of attackers discovering and exploiting vulnerable endpoints.

8. Security misconfiguration

Security misconfiguration occurs when an API is not securely configured, exposing it to various security risks. Examples of security misconfigurations include using default credentials, failing to turn off unnecessary features or neglecting to apply security patches promptly.

Mitigation Strategies:

• Set up your APIs with secure configurations at the early stages of development.
• Regularly review and update API configurations to ensure they continuously apply best security practices.
• Employ automated tools to detect and remediate security misconfiguration through continuous monitoring.

7. Server-side request forgery (SSRF)

Server-side request forgery (SSRF) is a vulnerability that allows an attacker to manipulate server-side requests, potentially leading to unauthorized access to internal resources or remote code execution. This can result in the exposure of sensitive data, disruption of critical systems or even complete system compromise.

Mitigation Strategies:

• Validate and sanitize user-supplied input used in server-side requests. This helps ensure that only legitimate requests are processed by your application and reduces the risk of SSRF attacks.
• Restrict the types of requests and resources that the API can access. Implementing strict access controls can help prevent unauthorized actions and limit the potential impact of SSRF attacks.
• Implement network segmentation and firewall rules to limit access to internal systems. You can reduce the likelihood of successful SSRF attacks by isolating sensitive resources from public-facing APIs.

6. Unrestricted access to sensitive business flows

Unrestricted access to sensitive business flows occurs when an API fails to implement proper access controls, allowing unauthorized users to perform sensitive operations or access confidential data.

Mitigation Strategies:

• Implement strong authentication and authorization mechanisms for all API endpoints.
• Apply the principle of least privilege, granting users the minimum necessary permissions to perform their tasks.
• Regularly audit and monitor API access logs to detect and respond to potential security incidents.

5. Broken function level authorization

A broken function-level authorization essentially refers to a situation in which a regular user can perform tasks that should be reserved for administrators due to an Insecure Direct Object Reference (IDOR) issue. This occurs when the user’s hierarchical permission system is incomplete or malfunctioning.

Mitigation Strategies:

• Implement strong authorization checks on all API endpoints.
• Use role-based access control (RBAC) to manage user permissions.
• Regularly review and update access control policies.

4. Unrestricted resource consumption

Unrestricted resource consumption, or denial of service (DoS) attacks, happens when an attacker exploits an API vulnerability to consume excessive amounts of system resources, such as memory, CPU or network bandwidth. This can lead to the degradation or complete unavailability of the affected service.

Mitigation Strategies:

• Monitor and limit resource usage.
• Implement rate limiting to control the number of requests from clients.
• Use caching to reduce the load on backend systems.

3. Broken object property level authorization

Broken object property level authorization is a security risk that occurs when an attacker can access or modify properties of an object that they should not have access to. This can happen if an API does not correctly validate user permissions before granting access to object properties.

Mitigation Strategies:

• Implement proper access control checks for all object properties.
• Validate user permissions before granting access to object properties.
• Use attribute-based access control (ABAC) to define granular access rules.

2. Broken authentication

Security issues arise when authentication protocols are not strong enough or properly executed. This results in open doors for attackers to breach an API undetected. Authentication weaknesses can manifest themselves in several ways, including but not limited to poor password creation best practices, compromised password storage systems and vulnerabilities within the token-based authentication framework.

Mitigation Strategies:

• Enforce strong password policies.
• Use secure password storage methods, such as bcrypt or Argon2.
• Implement multi-factor authentication (MFA) where possible.

1. Broken object-level authorization

Broken object-level authorization (BOLA) vulnerabilities occur when a user can access other users’ data due to the flaws in authorization controls validating access to data objects. BOLA vulnerabilities are often caused by insecure coding practices, such as failing to properly validate user input or check permissions before granting access to an object. This happens when an API uses overly permissive access controls or when API resources are not adequately protected.

Mitigation Strategies:

• Employ random, universally unique identifiers (UUIDs).
• Establish strong authorization protocols.
• Adopt the zero trust security framework.

Keep your APIs secure

Securing APIs requires a holistic approach that covers everything from authentication and authorization to access control and resource management. By taking the necessary steps to ensure your API and adopting best security practices, you can protect your applications and data from potential attacks while benefiting from the advantages of a robust API-driven architecture.

The post The top 10 API security risks OWASP list for 2023 appeared first on Security Intelligence.