Category: Americas

Source: Securelist – Kaspersky

Headline: Triada strikes back

Introduction

Older versions of Android contained various vulnerabilities that allowed gaining root access to the device. Many malicious programs exploited these to elevate their system privileges and gain persistence. The notorious Triada Trojan also used this attack vector. With time, the vulnerabilities were patched, and restrictions were added to the firmware. Specifically, system partitions in recent Android versions cannot be edited, even with superuser privileges. Ironically, this has inadvertently benefited malicious actors. While external malware now faces greater permission restrictions, pre-installed malware within system partitions has become impossible to remove. Attackers are leveraging this by embedding malicious software into Android device firmware. This is how one of our earlier findings, the Dwphon loader, functioned. It was built into system apps for over-the-air (OTA) updates. In March 2025, our research highlighted the Triada Trojan’s evolved tactics to overcome Android’s enhanced privilege restrictions. Attackers are now embedding a sophisticated multi-stage loader directly into device firmware. This allows the Trojan to infect the Zygote process, thereby compromising every application running on the system.

Key takeaways:

• We discovered new versions of the Triada Trojan on devices whose firmware was infected even before they were available for sale. These were imitations of popular smartphone brands, and they remained available from various online marketplaces at the time of our research.
• A copy of the Trojan infiltrates every application launched on an infected device. The modular architecture of the malware gives attackers virtually unlimited control over the system, enabling them to tailor functionality to specific applications.
• In the current version of Triada, the payloads we have analyzed exhibit several malicious behaviors depending on the host application. Specifically, they can modify cryptocurrency wallet addresses during transfer attempts, replace links in browsers, send arbitrary text messages and intercept replies, and steal login credentials for messaging and social media apps.

The complete infection chain looks like this:

Kaspersky products detect the new version of Triada as Backdoor.AndroidOS.Triada.z..

System framework with a malicious dependency

Our initial investigation focused on native libraries included in the firmware of several devices, located in:

• /system/framework/arm/binder.so
• /system/framework/arm64/binder.so

The file is not present in a reference Android version. We discovered that the suspicious library was loaded into Zygote, the parent process for every Android application, by an infected AOT-compiled Android system framework ( boot–framework.oat) located in the same directory.

The binder.so library registers a native method, println_native, for the android.util.Log class, used by applications installed on the device to write messages to Logcat. The implementation of this method calls a suspicious function, _config_log_println.

The _config_log_println function then calls two other functions that deploy three modules, contained in the rodata section of the malicious library, into every process launched on the device. One of the functions runs every time, while the other one only runs if the Android OS on the device is Version 9 or earlier.

Let us take a closer look at the modules that these launch.

1. Auxiliary module

This module from the rodata section of the malicious library is written to the application’s internal data directory under the name systemlibarm64_%N%.jar, where N is a random number.

The auxiliary module registers a receiver that can load arbitrary code files, although we did not see this happen in the cases described below. We would later call this module auxiliary because other payloads relied on it to perform their malicious functions. For example, for the com.android.core.info.config.JvmCore class from this module, binder.so registers native methods that can intercept calls to arbitrary methods within the process where the malware is running.

2. The mms-core.jar backdoor

This module undergoes a double XOR decryption process with different keys pulled from the rodata section of the malicious library. After decryption, it is saved to disk as /data/data/%PACKAGE%/mms-core.jar and then loaded using DexClassLoader. Once the loading is complete, the payload file is deleted.

This mms–core.jar is a new iteration of a backdoor we mentioned in our earlier reports. In contrast to past versions, which exploited and modified system files to load itself into Zygote, the malware now achieves reliable Zygote access by leveraging a compromised system framework. Similar to previous versions, the backdoor downloads and executes other payloads.

3. Crypto stealer or dropper?

Immediately upon starting, the binder.so library reads the file /proc/%PID%/cmdline, with %PID% representing the system process ID. This is how the Trojan determines the package name of a running app.

Based on the package name, binder.so loads either a crypto stealer loader (if the application is cryptocurrency-related) or a dropper from the rodata section. Neither payload is encrypted.

Triada crypto stealer

In previous Triada versions we analyzed, cryptocurrency applications were immediately infected with a crypto stealer. However, in these latest samples, the malicious module is a loader specifically targeting apps with the following package names:

The entry point for this malicious loader is the onCreate method within the com.hwsen.abc.SDK class. In latest versions this module requests a configuration from a GitHub repository. Using a pseudo-random number generator, the sample selects a number (0, 1, or 2), each corresponding to a specific repository address.

All field values within the configuration are encrypted using AES-128 in ECB mode and then encoded with Base64. An example of a decrypted configuration is shown below:

If online equals true, the loader downloads a payload from the URL specified in the durl field. If errors occur, it uses durl2 and durl3 as backup links. The downloaded payload is decrypted using XOR with a hardcoded key and saved to the application’s internal data directory under the name specified in the vname parameter. The pkg and method fields represent the class name and method, respectively, that will be called after the crypto stealer is loaded via DexClassLoader.

The downloaded payload attempts to steal the victim’s cryptocurrency using various methods. For example, it monitors running activities at preset intervals. This allows the Trojan to intercept attempts at withdrawing cryptocurrency and replace the victim’s crypto wallet addresses in the relevant text fields with addresses belonging to the attackers. To achieve this, the malware runs a depth-first search for all graphical sub-elements within the current frame, identifying the blockchain to which the funds are being sent. The Trojan then swaps the crypto wallet address with a hardcoded one and replaces the click handlers of all buttons in the application with a proxy handler that swaps the crypto wallet address again, ensuring the attackers can steal the funds. Interestingly, the crypto stealer also replaces image elements with generated QR codes containing attacker-controlled wallet addresses.

The Trojan also monitors the clipboard contents and, if it finds a crypto wallet address, it gets replaced with an address belonging to the attackers.

Dropper

If the binder.so library happens to run in an app unrelated to cryptocurrency, it downloads a different payload. This is a dropper that calls the onCreate method within the com.system.framework.api.vp2130.services class. Depending on the version, it can extract up to three Base64-encoded additional modules from its own contents.

• The dropper loads a com.android.packageinstaller.apiv21.ApiV21 class from the first module inside the system APK installer app. This class registers a receiver that allows other modules to install arbitrary APKs on the device and also uninstall any apps.

Beginning with Android 13, apps from untrusted sources are restricted from accessing sensitive permissions, such as those for accessibility services. To bypass these restrictions for sideloaded apps, the receiver installs them through an installation session in newer Android versions.

• The com.system.framework.audio.Audio class is loaded from the second module to block network connections. Depending on the system architecture, it decodes and loads a native helper library. This library uses the xhook library to intercept calls to the getaddrinfo and android_getaddrinfofornet functions. These functions handle communication with the dnsproxyd service in Android, which performs DNS requests using a client-server model. If the attackers have sent a command to block a specific domain, its name is replaced by a hook redirecting to 127.0.0.1, making access to the original domain impossible.

Thus, the malware can block requests to anti-fraud services unless they use a custom DNS implementation.

• The com.system.framework.api.init.services class is also loaded from the third module to download arbitrary payloads. For this purpose, the malware periodically transmits a wealth of device information (MAC address, model, CPU, manufacturer, IMEI, IMSI, etc.), along with the host application name and version, to its command-and-control server. Before being sent, the data is encrypted using AES-128 in CBC mode and then encoded with Base64. The C2 responds with a JSON file containing information about the payload, also encrypted with AES-128 in CBC mode. The infected device receives the key and initialization vector (IV) RSA-encrypted from the C2 within the same JSON.

For convenience, we will refer to this module as the Triada backdoor going forward. It is this module that holds the greatest interest for our research, as it provides the malware with a wide range of capabilities. A closer look at the Triada threat actor’s objectives yielded a somewhat surprising result. Whereas previous malicious samples mainly displayed ads and signed users up for paid subscriptions, the attackers’ priorities have now drastically changed.

What Triada downloads

To understand exactly how the attackers’ priorities have shifted, we decided to try downloading the payloads for various popular apps. We observed that the binder.so malicious library passes a flag to the dropper upon starting if the application’s name is on a list within its code. This list included both system apps and popular apps from official stores.

This list served as the starting point for our investigation. For all the listed applications, we sent requests to the malware C2, and some of them returned links to download payloads. As an example, this is the response we received from the Trojan after requesting a payload for Telegram:

The payload information from the C2 server was received as an array of objects, with each containing two download URLs (primary and backup), the MD5 hash of the file to download, the module’s entry point details, and its ID. After downloading, the modules were decrypted twice using XOR with different keys.

In addition to this, the response from the C2 contained other package names. By using these, we were able to obtain various further payloads.

It should be noted that according to the Android security model, unprivileged users do not normally have access to certain application data. However, as mentioned earlier, the malware is loaded by the Zygote process, which allows it to bypass OS restrictions because each payload runs within the process of the app it targets. This means the modules can obtain any application data, and the attackers actively exploit this in subsequent stages of infection. Furthermore, each additional malware payload can use all the permissions available to the app.

During module analysis, we also noted the significant skill of the Triada creators: each payload is tailored to the target app’s characteristics. Let us see which modules the Trojan loaded into some popular Android apps.

Telegram modules

For the Telegram messaging app, the Triada backdoor downloaded two modules at the time of this research. The first module (b8a745bdc0e083ffc88a524c7f465140) launches a malicious task within the messaging app’s context once every 24 hours. We believe that the attackers thoroughly examined Telegram’s internal workings before coding this task.

Initially, the malicious task tries to obtain the victim’s account details. To do this, the module reads a string associated with the user key from the key-value pairs saved using SharedPreferences in the app settings XML file named userconfig. The string contains Base64-encoded serialized data about the Telegram user, which the messaging client code deserializes to communicate with the API. The malware takes advantage of this: Triada tries several reflection-based methods to read the user data.

The malware sends the following user information to the C2 server if it has not done so previously:

• A serialized string containing the victim’s account details.
• The victim’s phone number.
• The contents of the tgnet.dat file from the application’s data directory.
  This file stores Telegram authentication data including the user’s token, which allows the attackers to gain complete control over the victim’s account.
• The string with id=1 from the params table in the cache4.db database.

This payload also contains unused code for displaying ads.

The second module (fce117a9d7c8c73e5f56bda7437bdb28) uses Base64 to decode and then execute another payload (8f0e5f86046faed1d06bca7d3e48c0b8). This payload registers its own observer for new Telegram messages, which checks their content. If the message text matches regular expressions received by the Trojan from the C2 server, the message is deleted from the client. This module also attempts to delete Telegram notifications about new sessions.

Additionally, the malware tries to initiate a conversation with a bot that was no longer there at the time of our research.

Instagram module

This module (3f887477091e67c6aaca15bce622f485) starts by requesting the device’s advertising ID from Google Play services, which it then uses as the victim ID. After that, a malicious task runs once every 24 hours, sequentially scanning all XML files used by SharedPreferences until it finds the first file whose name begins with UserCookiePrefsFile_. This file contains the cookies for active Instagram sessions, and intercepting these sessions allows the attackers to take over the victim’s account. The task also collects all files ending in batch from the analytics directory inside data.

These files, along with information about the infected device, are encoded in Base64 and sent to the C2 server.

Browser module

This module (98ece45e75f93c5089411972f9655b97) is loaded into the browsers with the following package names:

• com.android.chrome
• org.mozilla.firefox
• com.microsoft.emmx
• com.microsoft.emmx.canary
• com.heytap.browser
• com.opera.browser
• com.sec.android.app.sbrowser
• com.chrome.beta

First, it establishes a connection with the C2 server over TCP sockets. Then, using the RSA algorithm, it encrypts an IV and key concatenation for AES-128 in CBC mode. The Trojan uses AES to encrypt the information about the infected device and then combines it with the key and IV into a single large buffer, which it sends to the TCP socket.

The C2 server responds with a buffer encrypted with the same parameters as the request it received from the infected device. The response contains a task to periodically substitute links opened in the browser. An example of this task is shown below.

The link replacement works as follows. The module first checks the version and name of the browser that it is running in to register hooks for the methods that the browser uses for opening links.

We noted earlier that in the initial stages, the Trojan downloaded an auxiliary module that implements its functionality to intercept arbitrary methods. The browser module utilizes this to interfere with the process of opening pages in various browsers.

In addition, the malware uses reflection to replace the Instrumentation class instance for the app. The execStartActivity method, which launches app activities, is replaced in the proxy class.

In Android, application activities are launched by broadcasting an intent with a specific action. If the application has an activity with an intent filter that declares the ability to handle the action, Android will launch it. When an application opens a link in a browser, it creates and sends an Intent instance with the action android.intent.action.VIEW, including the URI to be opened. Triada substitutes the URI in the received Intent instance.

In the samples we analyzed, the C2 server sent links to advertising resources. However, we believe that the malware creators could also use this functionality for, say, phishing.

WhatsApp modules

For WhatsApp, the Trojan’s C2 server would provide two modules. One of these (d5bc1298e436424086cb52508fb104b1) runs a malicious task within the WhatsApp client’s context every five minutes. This task reads various keys essential for the client’s operation, as well as data about the active session.

This data, along with information about the victim’s device, is forwarded to the C2 server, giving the attackers complete access to the victim’s WhatsApp account.

The other module (dc731e55a552caed84d04627e96906d5) starts by intercepting WhatsApp client functions that send and receive messages. The threat actor employed an interesting technique to work around class name obfuscation in WhatsApp code. The module’s code contains the names of the class and method being intercepted, specific to different WhatsApp versions. This likely required the attackers to manually analyze how each version worked. It is worth noting too that if the module’s code lacks the class names for the specific client version, the malware can request an interception configuration from the attackers’ C2 server.

If the interception is successful, the module continues its operation by sending data about the infected device to the C2 server and receiving a TCP socket IP address in response. Commands are then transmitted through this socket, allowing the malware to perform the following actions:

• Send arbitrary WhatsApp messages.
• Delete sent messages on the device to cover its tracks.
• Close the connection.

LINE module

This module (1d582e2517905b853ec9ebfe77759d15) runs inside the LINE messaging app. First, the malware gathers information about the infected device and sends it to the C2 server. Subsequently, every 30 seconds, it collects internal app data, specifically the PROFILE_AUTH_KEY and PROFILE_MID values from the settings table in the naver_line database. The malicious module also obtains the User–Agent string and additional information to mimic HTTP requests as if they were coming from the messaging client itself. Additionally, the malware decrypts the user’s phone number and region from the naver_line database and uses reflection to obtain the application’s access token, which allows it to take over the victim’s account.

The module sends the data it collects to the C2 server.

Skype module

This module (b87706f7fcb21f3a4dfdd2865b2fa733) runs a malicious task every two minutes that attempts to send information about the infected device to the C2. Once the C2 accepts the request, the task stops, and the Trojan begins reading internal Skype files every hour. Initially, the module tries to extract a token that allows access to the Skype account from the React Native framework keychain.

Failing to obtain the token through this method, the malware then tries to locate it within WebView cookies.

This token is then sent to the Trojan’s C2 server, thus compromising the victim’s account.

The versions of Triada we have seen contain no payloads for Microsoft Teams or Skype for Business. However, we believe that after Microsoft sunsets Skype, the attackers might add new malicious modules for these apps.

TikTok module

This module (993eb2f8bf8b5c01b30e3044c3bc10a3) sends information about the infected device to the attackers’ server once a day. Additionally, the malware collects a variety of data about the victim’s account. For example, it reads cached TikTok cookies from an internal directory, which might have been used by WebView within the app. The attackers are interested in the msToken in these cookies, as it is necessary for interacting with the TikTok API. The module also extracts other information from the TikTok client, such as the user ID ( secUID), the User–Agent for API requests, and more. We believe that the attackers need this data to bypass TikTok API restrictions and simulate a real device when making API requests. Every five minutes, the malicious module attempts to send all data it collects to the attackers’ server.

Facebook modules

One of such modules (b187551675a234c3584db4aab2cc83a9) runs a malicious task every minute that compares the parent app package name against the following list:

• com.facebook.lite
• com.facebook.mlite
• com.facebook.orca

If the name matches one of the above, the malware steals the Facebook authentication cookies.

Another module (554f0de0bddf30589482315fe336ea72) sends data about the infected device to the C2. The server responds with a link to be opened in WebView, as well as JavaScript code to execute on the page. The malware can upload certain elements from this page to the C2 server, which potentially could be used by attackers to steal the victim’s account data.

SMS modules

These malicious components are injected into SMS apps. One of them (195e0f334beb34c471352179d422c42f) starts by registering its own proxy receiver for incoming SMS and MMS messages, as well as its own message observer. Following this, the malware retrieves rules from the C2 server, storing these in a separate database. The content of each received message is filtered on the basis of these rules.

The flexibility of these rules enables the malware to respond to specific SMS messages by extracting codes using regular expressions. We believe the Trojan creators primarily use this capability to sign victims up for paid subscriptions. Additionally, the module can send arbitrary SMS messages when instructed by the C2 server.

Interestingly, the module contains unused code snippets that are valuable for analysis — they also function as message filtering rules. Each rule includes a string value that defines its type: an MD5 hash of certain data. The module code contains methods named matchWhatsapp and matchRegister that use the same rule type. Analysis of matchWhatsapp revealed that this malicious component previously could cover other modules’ tracks and delete SMS messages containing verification codes for logging in to the victim’s WhatsApp account. The use of the same rule type suggests that matchRegister is also employed by the malicious module to conceal its activity, possibly to secretly register accounts. This method is likely obsolete because the malware now supports receiving rules from the C2 server.

The second module (2ac5414f627f8df2e902fc34a73faf44) is likely an auxiliary component for the first one. The thing is, Android performs a check on the addressee when an SMS is being sent. If the message is being sent to a short code (premium SMS), the user will be prompted to confirm their intention to send. This measure aims to prevent financial losses for device owners encountering SMS Trojans. The SMSDispatcher class in the Android framework checks if the app has permission to send premium SMS messages. To do this, it calls the getPremiumSmsPermission method within the SmsUsageMonitor class, which stores premium SMS sending policies for each application using the SharedPreferences mechanism with the key premium–sms–policy. The policies are integers that can take the following values:

• 1: User confirmation is required before sending a premium SMS.
• 2: The app is prohibited from sending premium SMS messages.
• 3: Sending premium SMS messages is allowed, and user confirmation is not required.

The malicious module sets the policy value for SMS messaging apps to 3, thereby clearing obstacles for the previous module. Notably, this is an undocumented Android feature, which further highlights the malware authors’ advanced skill level.

Reverse proxy

As far as we know, this module (3dc21967e6fab9518275960933c90d04), integrates into the Google Play Services app. Immediately upon starting, it transmits information about the infected device to the C2 server. The server responds with an IP address and port, which the malware uses to listen for commands via a modified version of the EasySocket library. The commands are integers that can take three values:

• 1: Establish a connection with an arbitrary TCP endpoint, assigning to it the ID transmitted in the command.
• 2: Terminate the TCP connection with the specified ID.
• 4: Send data over the TCP connection with the specified ID.

Thus, the main purpose of this module is to turn the infected device into a reverse proxy, essentially giving the attackers network access through the victim’s device.

Call interception

This module (a4f16015204db28f5654bb64775d75ad) is injected into the device’s phone app. It registers a malicious receiver that, upon receiving intents, can execute arbitrary JavaScript code using WebView.

The malware provides the JavaScript code with an interface to call certain Java functions. One of these functions takes the victim’s phone number and sends an intent that includes it.

The command number is transmitted in the type field of the intent. However, the module lacks a handler for this number. We assume that it is implemented in a different payload that we were unable to obtain during our investigation.

We also believe that this module is still under development. For example, similar to the browser module, it replaces the Instrumentation class to substitute the number opened using the android.intent.action.VIEW intent. However, the module lacks number substitution code.

We strongly believe the number substitution functionality exists in another version of this module or will be added in the near future.

Clipper

Our data indicates that this module (04e485833e53aceb259198d1fcba7eaf) integrates into the Google Play app. Upon starting, it requests a comma-separated list of attackers’ cryptocurrency wallet addresses from the C2 server. If it cannot get the addresses, the Trojan uses hardcoded ones. After that, the module checks the clipboard every two seconds. If it finds a cryptocurrency wallet address, it replaces it with one controlled by the attackers. Additionally, the malware registers an event handler for clipboard changes, where it also checks and swaps the content.

Additional module

In our previous report, we described the malicious modules downloaded by the initial Triada backdoor. We decided to check if the list of payloads had changed. Unfortunately, at the time of our research, the backdoor C2 server was not sending links to download additional modules. However, we noticed that the module entry points used a consistent special naming format – we will discuss this in more detail later. This allowed us to find another Triada malware sample in our telemetry. The module is named BrsCookie_1004 (952cc6accc50b75a08bb429fb838bff7), and is designed for stealing Instagram cookies from web browsers.

Campaign features

Our analysis of this Trojan revealed several interesting details. For example, it shows similarities to earlier versions of Triada (308e35fb48d98d9e466e4dfd1ba6ee73): these implement the same logic for loading additional modules as the mms–core.jar backdoor deployed by the infected framework.

Furthermore, lines starting with PPP appear regularly in the module code.

Functions from the binder.so malicious library set system properties similar to those in previous Triada versions. These and other similarities lead us to believe that the sample we analyzed is a new version of Triada.

While analyzing the modules, we encountered comments in Chinese, suggesting that the developers are Chinese native speakers. Additionally, one of the C2 servers used by the Triada modules, g.sxim[.]me, caught our attention. This domain was also used as a C2 server for a module of the Vo1d backdoor, suggesting a potential link to Triada.

Distribution vector

In all known infection cases, the device firmware had a build fingerprint whose last letter differed from officially published firmware fingerprints. Searching for similar fingerprints led us to discussion boards where users complained about counterfeit devices purchased from online stores. It is likely that a stage in the supply chain was compromised, with the vendors in online stores possibly being unaware that they were distributing fake devices infected with Triada.

Victims

According to KSN telemetry, our security solutions have detected over 4500 infected devices worldwide. The highest numbers of affected users were detected in Russia, the United Kingdom, the Netherlands, Germany, and Brazil. However, the actual number of infected devices could be much higher, given the unusual distribution method described in this article. The diagram below shows the TOP 10 countries with the highest numbers of users attacked between March 13 and April 15, 2025.

TOP 10 countries with the highest numbers of users attacked by Triada, March 13 – April 15, 2025 (download)

Separately, we decided to calculate the amount of cryptocurrency the Triada creators have stolen. To do this, we queried the Trojan’s C2 servers, receiving replacement wallet addresses in response. Findings from open-source research indicated that since June 13, 2024, the attackers had amassed more than $264,000 in various cryptocurrencies in wallets under their control. Below is a diagram showing the balance of several attacker-controlled wallets.

A profitability chart for the threat actor’s TRON wallets (download)

Conclusion

The new version of the Triada Trojan is a multi-stage backdoor giving attackers unlimited control over a victim’s device. The modular architecture provides its authors with a range of malicious capabilities, including targeted delivery of new modules and mass infection of specific applications. If your phone has been infected with Triada, we recommend following these rules to minimize the consequences of malicious activity:

• Install a clean firmware on your device.
• Avoid using messaging apps, crypto wallets, or social media clients currently on your device before installing new firmware.
• Use a reliable security solution to be promptly notified of similar threats on your device.

Indicators of compromise

Infected system frameworks

f468a29f836d2bba7a2b1a638c5bebf0
72cbbc58776ddc44abaa557325440bfb
fb937b1b15fd56c9d8e5bb6b90e0e24a
2ac4d8e1077dce6f4d2ba9875b987ca7
7b8905af721158731d24d0d06e6cb27e
9dd92503bd21d12ff0f2b9740fb6e529

Infected native libraries

89c3475be8dba92f4ee7de0d981603c1
01dff60fbf8cdf98980150eb15617e41
18fef4b6e229fc01c8b9921bb0353bb0
21be50a028a505b1d23955abfd2bdb3e
43adb868af3812b8f0c47e38fb93746a
511443977de2d07c3ee0cee3edae8dc8
716f0896b22c2fdcb0e3ee56b7c5212f
83dbc4b95f9ae8a83811163b301fe8c7
8892c6decebba3e26c57b20af7ad4cca
a7127978fac175c9a14cd8d894192f78
a9a106b9df360ec9d28f5dfaf4b1f0b5
c30c309e175905ffcbd17adb55009240
c4efe3733710d251cb041a916a46bc44
e9029811df1dd8acacfe69450b033804
e961cb0c7d317ace2ff6159efe30276a

Modules

Module C2 servers

lnwxfq[.]qz94[.]com
8.218.194[.]192
g.sxim[.]me
68u91[.]66foh90o[.]com
jmll4[.]66foh90o[.]com
w0g25[.]66foh90o[.]com
tqq6g[.]66foh90o[.]com
zqsvl[.]uhabq9[.]com
hm1es[.]uhabq9[.]com
0r23b[.]uhabq9[.]com
vg1ne[.]uhabq9[.]com
is5jg[.]3zweuj[.]com
qrchq[.]vrhoeas[.]com
xjl5a[.]unkdj[.]xyz
lvqtcqd[.]pngkcal[.]com
xc06a[.]0pk05[.]com
120.79.89[.]98
xcbm4[.]0pk05[.]com
lptkw[.]s4xx6[.]com
ad1x7[.]mea5ms[.]com
v58pq[.]mpvflv[.]com
bincdi[.]birxpk[.]com
773i8h[.]k6zix6[.]com
ya27fw[.]k6zix6[.]com

CDN servers for delivery of malicious modules

mp2y3[.]sm20j[.]xyz
ompe2[.]7u6h8[.]xyz
app-file.b-cdn[.]net

GitHub configurations

hxxps://raw.githubusercontent[.]com/adrdotocet/ott/main/api.json
hxxps://raw.githubusercontent[.]com/adrdotocet2/ott/main/api.json
hxxps://raw.githubusercontent[.]com/adrdotocet3/ott/main/api.json

Triada system properties

os.config.ppgl.ext.hws.cd
os.config.ppgl.btcore.devicekey
os.config.ppgl.version
os.config.opp.build.model
os.config.opp.build.status
os.config.ppgl.status
os.config.ppgl.status.rom
os.config.ppgl.build.vresion
os.config.hk.status
os.config.ppgl.cd
os.config.ppgl.dir
os.config.ppgl.dexok
os.config.ppgl.btcore.sericode
os.config.verify.status
os.config.alice.build.channel
os.config.alice.build.time
os.config.alice.service.status
os.android.version.alice.sure