Introduction to Rilide Rilide, also known as LumaC2 and CookieGenesis, is a sophisticated piece of malware that targets Chromium-based browsers to hijack user activity and steal sensitive data. Discovered in 2023, Rilide operates by leveraging browser extensions to carry out its attacks. Rilide abuses its browser extension component to inject its malicious scripts into web pages. In addition to its data exfiltration abilities, it also features advanced cryptocurrency theft capabilities, with 2FA manipulation for popular wallets and mail clients. Since the beginning of 2025, the Trusteer research lab has seen over 50,000 infected user sessions, indicating the scale of threat activity. Rilide has an ongoing WW campaign and was detected by the Trusteer lab attacking North America, South America, Europe, and Japan. In this post, we will explore how Rilide operates within the browser through its extension and examine the techniques it uses to carry out its attacks, particularly its impact on financial platforms. Rilide’s capabilities highlight the shift in the threat landscape from traditional web injections using single in-page JavaScript code, to browser extensions. Browser extensions facilitate many functions that are quite challenging to achieve without it. The following analysis shows how powerful an extension is, and why modern malware tends to use them. Man in the browser - then versus now In the past, most "man in the browser" attacks were executed by malware scanning browser memory to identify specific HTML patterns and injecting a <script> tag directly into the in-memory content of the page. Despite the malicious intent, these scripts were still subject to the browser’s security mechanisms, such as operating within a sandboxed environment, adhering to the same-origin policy, and being tied to the lifecycle of the page they were injected into. For example, the injected scripts could not access cookies or resources from other origins, nor could they persist or execute once the page was closed. In contrast, modern attacks using malicious browser extensions overcome most of these limitations. Extensions operate independently of any specific webpage, allowing them to run persistently in the background. They also have elevated privileges, enabling them to bypass same-origin restrictions, access browser-wide resources such as cookies or storage, and remain active even when no pages are open. This shift has made browser extensions a powerful tool for attackers, providing a level of persistence and control far beyond traditional web injection methods. Extensions also introduced a change in the JavaScript execution context, which has its own malicious benefits. Traditional web injections ran in the same context as the web application code, including security tools. Any evidence left behind (such as script elements, network requests, js variables, etc.) could make the malware detectable. Now, there are two different JavaScript environments in addition to the page context. 1.        First, there is the content script context which has access to the page document but is partially isolated from the main page environment. 2.        In addition, there is a background code context (a service worker), which has no access to the content script and main page environment. All the communications between those contexts happens through defined browser interfaces that aren’t visible to the page or its developers. Most extension behavior and evidence is isolated by design and detection is especially difficult if there is no change to the main document. Besides offering enhanced evasion, developing browser extensions is also straightforward, thanks to the extensive built-in functionality and permissions provided by modern browser APIs. The following analysis demonstrates how extensions make it easier to develop complex attacks. Given the increased control, persistence, evasion capabilities, and ease of development that extensions provide, the shift from traditional "man in the browser" techniques to extension-based attacks is not just understandable but inevitable in the evolution of browser-based threats. Deep dive into the Rilide browser extension Manifest breakdown We'll start our analysis of Rilide with the manifest file — a crucial component that outlines the extension's functionality and access levels, providing the first clues to understanding Rilide's malicious capabilities. One of the analyzed variants presents itself as a Google Drive extension: Figure 1:  Manifest extension description Later on, there is a list of required permissions. The list contains multiple critical browser functionalities, including but not limited to: ·      “scripting” - Allows injecting and executing JavaScript code on web pages. ·      “cookies” - Enables reading, modifying, or deleting browser cookies. ·      “webRequest” - Observing and modifying network requests made by the browser. ·      “clipboardRead/Write” – Reading and modifying user clipboard content. ·      “activeTab” - Temporarily accesses the content of the currently active tab.

Under “host_permission” the extension is allowed to access and interact with <all_ urls>, meaning any scheme, domain, path, and port supported by the browser.

“Content scripts” are also set to run on all URLs at document_start, meaning they execute as soon as the browser begins loading the page, before any content is fully rendered.

Figure 2: Manifest script configuration

The main.js script includes general information-stealing capabilities, while gmail.js targets the Gmail mail client page. Nonetheless, all scripts are injected into every page.

Under “declarative_net_request”, the extension configures rules to remove multiple CSP headers. This allows Rilide to bypass security restrictions and inject inline content.

Under “background”, the extension’s service worker is configured. This is where the malware monitors browser events and establishes communication with the C2 server. Next, we’ll delve into the background script analysis to better understand how the malware listens for browser events and executes its attack strategy.

Background.js script analysis 

Initialization

Background.js contains initialization code that is configured to execute upon the extension installation event. It fetches the device information such as CPU and storage details using chrome.system calls and installed extensions data using chrome.mangement. Unique ID is generated using the npm uuid module (imported via jspm) and saved to local storage. Finally, all cookies are fetched using chrome.cookies.getAll with an empty filter parameter.

Figure 3: Initialization code

This data is sent to the C2 server, and the response can enable the extension's proxy capabilities. Injections, commands, and malware settings are also fetched during the extension initialization.

The final part of the initialization is to enable the CSP removal rules, after which the malware is ready to set up and monitor browser events. Once again, we can clearly see the benefits of using a browser extension vs. traditional web-injecting techniques, making all of this information easily collected.

New domain extraction methods

Previous versions of Rilide had C2 domains hardcoded directly into the JavaScript files. Other variants extracted domains by retrieving transaction details from a specified Bitcoin wallet.

The new variant analyzed here includes code designed to fetch domains from a Telegram bot. Periodic calls to fetch the domains are set to run every minute using Chrome alarms.

This approach enables the malware to easily switch domains if one of them is detected and blocked.

Although this variant did not contain the Telegram tokens, it is likely that this method will appear in future versions.

Figure 4: Domain extraction from telegram bot

Ready for data exfiltration

The content script sends all of the page’s input elements values using chrome.runtime.sendMessage with the “new-grabber-info” message type.

The following listener is set in background.js to pass the data to the C2 server

Figure 5:Input data listener

In addition, the background is waiting for “set-screenshot-result” messages.

These messages trigger taking a screenshot using chrome.tabs.captureVisibleTab and sending the data back to the C2.

Figure 6: Taking a screenshot and forwarding the data

By employing these methods, if the user logs in to a banking site, a range of sensitive data can be stolen. This includes not only usernames and passwords but also account numbers, PIN codes, credit card details, security question answers, and transfer recipient information.

In the last part of the background scripts, periodic calls for command fetch and proxy checks are set using “chrome.alarms”. The command alarms fetch a list of commands from the C2 and executes them one by one.

The proxy check alarm checks proxy connection status and initiates a new one if needed. Once the listeners are set, the background script’s synchronous execution finishes.

cmds.js, what can the malware do?

cmds.js contains code that facilitates receiving a command (from a predefined list) along with parameters from the C2, and sending back any results, if applicable.

Some interesting commands include:

·      “extension” – Enable an extension based on a given ID

·      “push” – Create a browser notification with the fetched content and open a new tab on notification click

·      “screenshot” – Capture content of visible tab using “chrome.tab.captureVisibleTab”

·      “history” – Return browsing history

·      “cookies” – Fetch all browser cookies, same as in the initialization code

·      “url” – Open a new tab with the given URL

Other commands enable changing the extension configuration, fetching device information, current URL, and so on. This set of commands allows for dynamic changes in the malware's workflow and execution, making it more capable of enticing user interaction. Most of these commands utilize built-in Chrome extension functions which makes easy development for malware authors.

main.js content script: Custom injections and data theft
The main.js content script begins with the jQuery library initialized within an anonymous function, embedded entirely in-line without external imports. This is followed by obfuscated code executing malicious functions.

The Chromium extension architecture allows extensions to separate injection responsibilities and make it harder to detect. The service worker downloads and stores the injections during the initialization step, while the content script reads and executes them. No web requests were sent in the page context, which helps to keep the malware undetected. main.js iterates all fetched injections, and if the current URL matches the injection URL it injects it.

Rilide uses a clever way to inject scripts into the DOM.

Figure 7: Script injection

It creates an “onreset” document attribute with the injection as the event handler. It then immediately sends a custom “reset” event, which executes the injection, and finally removes the attribute.

This attribute is set at a specific time between the “setAttribute” call and the “removeAttribute” call, which makes it hard for security tools to detect.

The last function call sets up the generic data stealer listener.

Figure 8:Content script input listener (after deobfuscation and renaming variables)

Using a jQuery selector, all input elements are selected, and the “change” event listener is set.

The “change” event occurs every time the value of an input field is changed and loses focus (user clicks another element). For example, when a victim logs into their bank account their username is collected when they click the password field, and the password input is stolen when the user submits the form. The data is sent to the service worker via chrome.runtime.sendMessage, which then forwards it to the C2 servers.

gmail.js content script – hiding crypto theft
The goal of this script is to replace the withdrawal 2FA authorization request with a new device authorization request. We speculate that this approach keeps clients unaware of unauthorized withdrawals, as they are more likely to perceive the new device authorization as less suspicious than withdrawals.

The script starts with an in-line initialization of the jQuery library and a check that the current location contains “mail.google” before starting execution. The injection periodically checks for emails from popular cryptocurrency wallets and, if detected, invokes the corresponding wallet function.

Figure 9: Looking for crypto wallets emails

The jQuery selectors are quite simple, using “divs” that contain the wallet names in text.

We’ll demonstrate a specific vendor’s custom injection, although all of them act in a similar way.

The code searches for any elements containing the text “Withdrawal Request” and replaces it with “Authorize New Device”.

Figure 10:Changing withdrawal notification text

It also searches for span elements containing the text “withdrawal” to replace the email preview content.

Before injection:

Figure 11: Original withdrawal notification email

After injection:

Figure 12: New device notification email

The email body itself is found in the following way:

Figure 13: Changing email body content

Simply put, the script finds all the elements with CSS class “ii” which have a descendant “div” element with the “check address carefully” text. It also extracts the authorization code based on the element and style of the autherization code text. This method for identifying elements isn’t very stable, as small changes to styling, text, or structure can break it.

Figure 14: Withdrawal email HTML

Finally, the HTML content of the email is overwritten with hardcoded content.

Original content:

Figure 15: Original withdrawal notification

New content:

Figure 16: Injected email content

This mechanism allows the threat actor to withdraw cryptocurrencies without alerting the user about withdrawals.

Proxy code: From proof of concept to real world malware
Another standout feature that is implemented effortlessly through extensions is the proxy capability. Rilide enables converting the victim’s browser into an HTTP proxy, forwarding all requests while utilizing the victim’s credentials and data.

This capability is especially dangerous for financial fraud, as attackers can access banking portals, trading accounts, and payment platforms without triggering extra authentication checks. They can initiate transactions, modify account settings, or siphon funds under the guise of legitimate user activity, bypassing traditional security measures like IP address tracking. By effectively impersonating the victim, attackers can exploit trust-based mechanisms to commit fraud seamlessly.

This functionality was remarkably simple to implement as it was copied directly from CursedChrome, an educational project demonstrating a proof of concept for this type of attack.

The proxy works by using the extensions service worker to set up a WebSocket connection with the attacker's C2 server. This connection allows the service worker to receive commands sent by the attacker. These commands dictate the proxy's actions, such as making requests or navigating websites. Requests are made using the victim’s collected cookies and the responses are sent back to the C2.

CursedChrome code example:

Figure 17 :CursedChrome initialize function code

Rilide Code example:

Figure 18: Rilide startProxy function code

Besides some naming differences and function definition location, the code is the same. This project even comes with backend code and a management UI, making life easy for the attackers.

Staying safe with extensions

Rilide exemplifies how browser extensions have transformed the threat landscape for man-in-the-browser attacks. By leveraging the inherent capabilities of extensions, attackers gain unprecedented control over the browser, enabling sophisticated and persistent exploitation that far surpasses the limitations of traditional in-page web injections. This shift highlights the growing need for vigilance and robust defences, as the simplicity and power of extension-based attacks makes them an appealing vector for cybercriminals.

To protect themselves, users should regularly review their installed browser extensions, promptly removing any unfamiliar or suspicious ones.

Additionally, it's essential to monitor email accounts for unusual activity, such as unexpected login attempts, and keep a close eye on cryptocurrency wallets for unauthorized transactions or unknown actions. Staying proactive and cautious can help mitigate the risks posed by this evolving attack paradigm.

IBM Trusteer helps you to detect fraud, malwares, 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.

IOC:
Files:

Domain:
statbrwsr.digital