Russia-linked group APT29 targeted iOS and Android users through hijacked websites and a compromised analytics service.

Sekoia says a large-scale watering hole campaign is going after iOS and Android users, and it links the campaign to APT29 (aka SVR group, Cozy Bear, Nobelium, BlueBravo, Midnight Blizzard, and The Dukes), the Russian group tied to the SVR foreign intelligence service. A watering hole is a site that attackers poison so visitors infect themselves.

Sekoia found the campaign in mid-October 2026. It involved hacked or cloned high-profile websites in the US, Ukraine, the Czech Republic and Bulgaria. There’s also a supply-chain attack on a Ukrainian web analytics service, Plerdy, loaded by thousands of websites, most of them Ukrainian.

The attackers used three different methods to reach victims, but all led to the same malicious payload. They injected JavaScript into hacked websites, created fake websites that copied legitimate ones and secretly added malicious code, and compromised the Plerdy analytics service to infect websites using its script.

Sekoia first spotted the campaign on the website of a Ukrainian gas production company. Other compromised sites included a major US chemical industry association, a European far-right political party and a Bulgarian website linked to the military. In the Bulgarian case, attackers modified an existing JavaScript library without changing the website’s visible pages. Researchers found no clear pattern in the targeted organizations, although they believe some websites may have been selected to reach specific individuals.

Sekoia also identified two fake websites designed to impersonate legitimate services. One copied America250, the US initiative marking the country’s 250th anniversary, while another reproduced the website of Raffles London at The OWO, a luxury hotel close to the UK Ministry of Defence and Downing Street.

“The second website, theowo[.]club, now offline, acted as a reverse proxy for the website of Raffles London at The OWO, a prestigious luxury hotel housed in the historic Old War Office building.” reads the report published by Sekoia. “The hotel’s location is particularly noteworthy because of its proximity to some of the United Kingdom’s most sensitive government institutions, including the Ministry of Defence and 10 Downing Street, the official residence and office of the British Prime Minister.”

The hotel connection is particularly interesting because Ukrainian President Volodymyr Zelensky reportedly stayed there during a visit to London on October 14. Sekoia believes the fake website may have been used to target diplomatic delegations through spear-phishing, but stresses that this remains an unconfirmed possibility.

Between August 27 and September 3, 2026, the attackers compromised the Plerdy tracker at a.plerdy[.]com. For a week, visitors loaded both Plerdy’s script and the attackers’ profiling script. Several affected sites relate to the military and military recruitment, including army, special forces and military equipment websites.

“Between 27 August and 3 September 2026, the intrusion set compromised the Ukrainian Plerdy analytics tracker hosted under the domain a.plerdy[.]com, which is loaded by thousands of websites, the large majority of them Ukrainian.” reads the report. “It remains unclear whether the attackers intended to target visitors to specific websites or sought to compromise as many unpatched mobile devices as possible, indiscriminately exfiltrating data before selectively identifying and exploiting information of interest.”

Sekoia can’t say whether the aim was specific visitors or as many unpatched phones as possible, with the sorting done later. It also considers that the attackers may have used Plerdy after failing to inject code directly into Ukrainian high-value sites that relied on it. The Plerdy payload pointed to a load-balancing domain that sent traffic across several delivery servers.

The profiling script, which the attackers call UltimateFingerprinter, is attached to a minified AngularJS library that makes up 98 percent of a 2.3 MB file. Sekoia thinks that bulk might stop analysis by large language models, or make the script look legitimate. The script runs 61 collectors that build 394 fields, then sends them to a server that decides whether to answer with exploit code.

Strangely, almost none of that data matters. Only implausible screen sizes, like 99999, or a device reporting zero touch points block delivery. Sekoia doesn’t know why the attackers collect so much and sees no sign the data was used later.

Sekoia pulled three exploit chains from the delivery server. Class A hits iOS 16.7 and steals cookies. Class B hits iOS 18.5 and takes full device data. Class C hits Android Chrome versions 139 to 145, minus 143 for reasons Sekoia can’t explain, and steals Chrome cookies and Wi-Fi passwords.

“During the investigation, we tested different browser profiles against the fingerprinting endpoint at static[.]flux-telemetry[.]com in order to retrieve the exploits served to visitors.” states the report. “This allowed us to retrieve three complete exploit chains (afternamed A, B and C), along with their final payloads, targeting both Android and iOS. Here is a summary of what we found:”

Class B is DarkSword, which Sekoia describes as a suspected iOS exploit kit from a commercial surveillance vendor, uploaded to VirusTotal in September 2026. It takes text messages and iMessages, Mail indexes, voicemail, WhatsApp and Telegram databases, Keychain passwords and tokens, account credentials and Wi-Fi keys. It also takes contacts, call history, calendar, notes, Safari history and cookies, location caches, Health data, photos and iCloud Drive.

The Android payload, which Sekoia calls AndroSnitch, collects Chrome cookies, saved logins and history, plus Wi-Fi settings. It stops on one phone model, the Samsung Galaxy S25 Ultra. It resembles a 2024 payload that Google TAG documented, called AndroSnatch, but the sample is too small to prove lineage. The iOS cookie chains set a marker cookie meant to block reinfection for a day, but a coding mistake makes it expire in a minute.

All stolen data goes to ad.starx-net[.]com:8881/telemetry/v12. None of the chains persist on the device. All of them rely on known flaws, and none uses a zero-day.

For attribution, Sekoia has several threads. A CERT said a compromised site’s backend files held traces matching a private report on a 2025 APT29 watering hole campaign, and Google TAG said the framework resembles an APT29 campaign against Mongolian government websites in 2024. Victims also skew to Europe and the US with a focus on Ukraine, infrastructure sits across multiple hosters, and a hacked Czech far-right site fits APT29’s record of targeting European political parties. It rates the link moderate to high confidence, and it’s coordinating with the CERTs of affected countries.

The campaign shows how exploit kits move down the market. Sekoia says state-backed groups keep reusing frameworks from commercial surveillance vendors such as DarkSword, and that packaged exploit chains lower the cost and skill needed for advanced mobile attacks. It expects such reuse to become more frequent.

The good news is that Sekoia’s attackers don’t have fresh tricks. Every flaw was fixed by its vendor before the campaign began, and none works against fully updated devices.

“None of them contain zero-days or work against fully updated devices. Each flaw was resolved by the respective vendor before this campaign began. This operation targets unpatched devices using n-days; a user running an up-to-date operating system is safe from these attacks.” concludes the report.

“This watering hole campaign, which we assess with moderate to high confidence to be linked to APT29, combines multiple web delivery vectors with n-day mobile exploit chains targeting Android and iOS devices. Across the directly compromised websites, no single sectoral targeting pattern emerges from our analysis. While the victimology shows a focus on Ukraine and the United States, the inclusion of unrelated entities such as an Australian medical clinic complicates a broad strategic interpretation. However, we assess that these websites may have been selected to profile and infect specific individuals of interest based on targeting intelligence to which we do not have visibility. The operators adapted by deploying Adversary-in-the-Middle-ish to intercept visitors associated with diplomatic or high-profile events.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, APT29)

Critical Android flaw CVE-2026-58868 could allow remote code execution without user interaction on devices running Android 14 through 17.

Google has fixed CVE-2026-58868, a critical Android vulnerability affecting versions 14 through 17. The flaw is a critical Android vulnerability caused by a heap buffer overflow in the onOutputReceived function of FrameDecoder.cpp. The flaw can trigger an out-of-bounds write, potentially allowing a remote attacker to execute arbitrary code on a vulnerable device. Exploitation requires neither user interaction nor additional execution privileges, making it a potential zero-click attack.

“cve-2026-58868 In onOutputReceived of FrameDecoder.cpp, there is a possible out-of-bounds write due to a heap buffer overflow.” reads the advisory. “This could lead to remote code execution with no additional execution privileges needed. User interaction is not needed for exploitation.”

Devices receive the fix through security patch level 2026-11-01 or later, depending on manufacturers and carriers. Google is not aware of active exploitation of the flaws in its November 2026 bulletin.

Google’s November 2026 Android security bulletin addresses 216 vulnerabilities, including 23 rated Critical. Two of these flaws, CVE-2026-58876 and CVE-2026-58936, affect the System component and could allow remote code execution without user interaction.

The bulletin also lists five other Critical flaws in the System component. Three could lead to privilege escalation, while two could cause denial-of-service conditions. Another Critical vulnerability affects the Framework component and could also allow remote code execution.

Six Critical vulnerabilities affect the Android kernel. Two involve Bluetooth code, three affect the protected Kernel-based Virtual Machine (pKVM), and one is in the Human Interface Device (HID) component. The most severe kernel flaw could allow a remote attacker to gain elevated privileges without user interaction.

The November 5 patch level also addresses Critical vulnerabilities in MediaTek modem code and a closed-source Qualcomm component. Google’s bulletin lists eight Critical MediaTek modem flaws, while MediaTek’s own November security bulletin details six of them: CVE-2026-20499 and CVE-2026-20545 through CVE-2026-20549.

MediaTek describes these six vulnerabilities as out-of-bounds write flaws caused by missing bounds checks, integer overflow or improper input validation. The company says it is not aware of any active exploitation in the wild.

The Qualcomm issue is tracked as CVE-2026-25285 and affects a closed-source component. Google does not provide further technical details in its bulletin.

One of the critical issues fixed by Google is CVE-2026-58882 (aka SMS of Death), which could allow attackers to remotely disable a phone by sending a specially crafted SMS message. The flaw affects decodeWapPdu, a function responsible for processing WAP Push messages, a type of content delivered through the SMS infrastructure.

The vulnerability is particularly concerning because exploitation reportedly requires no user interaction. An attacker only needs the victim’s phone number to send a malicious message. The message doesn’t appear in the SMS inbox, so the victim may have no indication of what caused the problem.

The issue also raises concerns about the reliability of mobile communications during an attack. According to a technical analysis published on October 29 by security researcher Mark B, a malformed WAP Push message can crash com.android.phone, the Android system component responsible for handling telephony functions. The crash can terminate ongoing calls, including emergency calls.

Tests on several Android phone models reportedly reproduced the crash consistently. The phone can also become stuck in a crash loop because Android retries processing the malicious message whenever the device starts. As a result, the device may continue crashing until the offending message is removed.

There is an important distinction, however. Google’s security bulletin and the CVE record identify the vulnerable decodeWapPdu function, but neither explicitly confirms that CVE-2026-58882 is the same issue described in the researcher’s SMS of Death report. The technical overlap is worth investigating, but the two reports shouldn’t be treated as definitively describing the same vulnerability without further confirmation.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, CVE-2026-58868)

SMS of Death lets attackers crash Android call services with a hidden, zero-click message, blocking phone calls, even emergency calls too.

A specially manipulated SMS message is enough to crash Android’s phone service, interrupt ongoing calls, and temporarily render the smartphone unusable. The attack requires no interaction from the victim and can even compromise the ability to contact emergency services.

The vulnerability, dubbed the SMS of Death, is bringing renewed attention to the security of the messaging system in Android smartphones. The issue, documented by independent researcher Mark Blaszczyk, allows a remote attacker to cause a disruption in phone service by sending a single, specially crafted WAP Push message.

WAP Push (Wireless Application Protocol Push) is a particular message transmitted over the mobile network, generally in the form of a binary SMS, which contains structured data and is processed automatically by the smartphone without requiring user intervention. Unlike a traditional SMS, it can carry notifications, links to Internet resources, and configurations for mobile services.

The most worrying aspect is the execution method. It’s a zero-click attack, in which the recipient doesn’t have to open the message, select a link, or authorize any action. The content is automatically processed by the operating system and can cause the process responsible for phone functionality to crash.

The vulnerability affects “WapPushOverSms“, an Android framework component located in the “frameworks/opt/telephony” path, responsible for interpreting and managing WAP Push messages received by the device.

The technical cause lies in the incorrect handling of a numeric value used during message interpretation. Specifically, the “decodeWapPdu()” function, the researcher explains, reads the length of the WSP header through a value encoded as “uintvar” , initially returned as a 64-bit number. The value is subsequently converted to a 32-bit integer without prior range checking. This operation can transform a seemingly valid number into a negative value, which is then used to determine the size of an array. The consequence of this is a “NegativeArraySizeException” exception, thrown when Android attempts to allocate a negative-sized array. The exception is not handled correctly in the processing path and causes the “com.android.phone” process, responsible for telephony functions, to terminate.

The researcher demonstrated that a five-byte WSP header can generate the value “-2147483648“, which is sufficient to trigger the issue. Therefore, it is not necessary to transmit particularly large amounts of content to cause the issue.

“A 5-byte uintvar of 88 80 80 80 00 decodes to 0x80000000. Cast to a signed 32-bit int, that is -2147483648. Allocating new byte[-2147483648] throws an uncaught NegativeArraySizeException on the telephony main thread, killing com.android.phone:” reads the analysis.

An invisible attack that also interrupts emergency calls

The message is transmitted as a data SMS via the WAP Push channel on port 2948. Unlike a regular SMS, it isn’t displayed in the message inbox and doesn’t generate a user-recognizable notification. The sender’s number isn’t normally visible in the conversation, and when the device receives the message, Android automatically starts processing it. A crash in the phone process causes a temporary loss of connectivity and interrupts active voice calls, including those to emergency services.

According to the researcher’s published evidence, each message processing can cause a disruption in telephone service lasting about one to two seconds, during which the component is rebooted. However, the problem can become much more serious if the message is processed repeatedly.

One of the most significant aspects of SMS of Death is the ability to transform a simple crash into a persistent Denial of Service condition. The malicious message can remain in the incoming SMS queue and be reprocessed during subsequent delivery attempts. The telephone operator’s retransmission mechanism can also contribute to a repeat of the event, causing further service disruptions.

The researcher reports observing intermittent crashes for up to a week after receiving a single message. Sending around twenty specially crafted messages can render the device unusable for an extended period. In more severe cases, the phone process can continue to crash during system startup, triggering a condition similar to a boot loop. Recovery may require using the Android Debug Bridge (ADB) on a computer, directly intervening in the queue of messages waiting to be processed. For a typical user, this is far from a simple procedure.

A threat to communications availability

SMS of Death demonstrates how a cyberattack doesn’t necessarily have to involve information theft, code execution, or device control to have significant consequences. In this case, the target is phone service availability, a crucial feature especially when contacting emergency services. The ability to interrupt communications without any user interaction makes this vulnerability particularly sensitive. To reduce exposure, it’s important to check the Android security patch level installed and apply available updates, paying particular attention to devices no longer receiving manufacturer support.

Testing conducted by Mark Blah has shown that the issue is reproducible on several devices, including the Google Pixel 9 and Samsung smartphones from the Galaxy and Galaxy A families. The vulnerable code appears to be present on Android versions ranging from Android 12 to Android 17. However, the availability of the fix is ​​not uniform across all generations of the operating system.

According to documentation published by the researcher, Google has distributed a fix via the October 2026 security update for Android 14, 15, 16, and 17. Older devices, such as those running Android 12 and 13, may remain exposed if they do not receive corrective updates.

About the author: Salvatore Lombardo (X @Slvlombardo)

Electronics engineer and Clusit member, for some time now, espousing the principle of conscious education, he has been writing for several online magazine on information security. He is also the author of the book “La Gestione della Cyber Security nella Pubblica Amministrazione”. “Education improves awareness” is his slogan.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, SMS of Death)

uCreater is Android spyware disguised as trusted apps, stealing credentials, messages and wallet data through a rentable platform.

uCreater is a rentable Android spyware platform that hides inside repackaged legitimate apps, targeting messaging services and mobile wallets. Its YingGai framework can intercept one-time passwords, steal account and chat data, collect contacts, manipulate sessions and spoof camera feeds to bypass identity checks. Victims may install modified versions of Telegram, WeChat or GCash through sideloading or social engineering.

Researcher Ovi found stolen data on a control server, but the number of victims and links between operators and customers remain unconfirmed.

“The repackaged APK can be relatively thin: target-specific instrumentation is retrieved after installation from the operator’s Alibaba OSS and MinIO infrastructure, including buckets and paths named Huuk_<target> and fengzhuang-app (literally, “packaging”). Distribution hosts include telegram-apk.uzyzx.com.” researcher Ovi states. “I could reconstruct much of the post-installation execution chain from the recovered code, but I could not directly establish the initial delivery mechanism for every victim.”

Ovi rebuilt most of the chain from recovered code but couldn’t establish how every victim got the first install.

The product is older than the samples. The package com.ucreater.autotool dates to about 2014, Windows tools tied to ucreater.com were signed between 2016 and 2019, and the YingGai mobile line shows up in records from September 2021. The samples Ovi studied run from 2024 to 2026: uip.exe builds from February to December 2024, Telegram repacks from July and November 2024, the WeChat host and Telegram framework from December 2024, and the Onion Box client from March 2026. The control server’s ICP filing, 湘ICP备2024061212号, dates to 2024.

The infrastructure hints at scale, though not at victim numbers. Ovi counts about 20 target apps with confirmed code support, six operator domains with dozens of subdomains, three Redis buses, two MQTT buses, and a cloud-phone cluster in Changsha spread across several ISPs. A Censys search for the operator’s Tengine gateway fingerprint returned roughly 48 hosts. It looks like a multi-year product sold to many downstream operators, but he can’t say how many customers used it or how many devices fell.

Attributing the platform to a specific legal entity is more difficult. Hunan Youchuang Technology is linked to the ucreater.com brand and a self-signed certificate on videoflow.cn. Changsha Sukai Network holds the ICP filing for the control server’s main domain, qianxuncc.cn, while Changsha Zhuoqing E-commerce appears as the signing identity on uip.exe, using a DigiCert certificate. A common owner is plausible but unproven.

Another lead involves hunanzhijing.com, a domain belonging to the Hunan Intelligent Police Public Safety Technology Research Institute. It shares the same gateway fingerprint, and an official Hunan document connects the institute to an intelligent-policing research project. However, shared cloud infrastructure establishes only co-tenancy, not ownership or operational involvement. There is no evidence that the police developed or operated uCreater.

Other infrastructure links also require caution. A Thailand-based relay used by the Telegram component, hosted on Huawei Cloud, also served gambling websites, an advertising-account service and an SMS service. The cloud-phone web client displayed a certificate for another vendor, while the gateway served a Vue application titled 舆情交易, meaning “public-opinion trading”. These observations are leads for further investigation, not proof of common ownership.

uCreater relies on app virtualization, a technique already identified by Zimperium as a growing mobile threat. VirtualApp runs another application inside a container, LSPatch merges code hooks into repackaged apps without requiring root access, and Pine hooks Android’s runtime. Together, these components allow malicious code to operate inside a legitimate app while it is signed in and has access to decrypted data.

“uCreater is notable because it turns these techniques into a reusable, remotely managed product.” the researchers continues.

Operators distribute modified versions of Telegram-X, Telegram-Web and other messaging apps, integrating modules through LSPatch or loading them from an asset called TgJarPine.dex. WeChat can instead run inside a VirtualApp container, including the va_vx or Onion Box host. LSPatch also stores the original APK under cache/lspatch/origin/*.apk. The presence of this path or the specific asset can help identify an infected device.

The approach differs from GodFather, a banking trojan documented by Zimperium that runs apps in a virtual container and displays fake overlays to capture credentials. uCreater operates inside the real application without relying on an overlay. It uses XposedBridge hooks, reflection and access to the app’s own database interfaces. This allows it to reach beyond login screens and potentially support any application for which the vendor develops a module. Ovi found no evidence linking the two platforms.

One distinguishing feature is a local command server embedded in each hooked application. It exposes around 40 numbered handlers, with descriptions and parameters that allow operators to discover available functions. The code supports device monitoring, contact and SMS collection, installed-app enumeration, message sending, chat-history retrieval, session management and account-related actions.

The Telegram module can execute SQL queries directly against the application’s live database through its own interface. Its Db_MessagesStorageRawQuery handler accepts operator-supplied SQL and returns results through compatibility classes that recreate Telegram objects. This can expose information that would otherwise be protected in the app’s encrypted or locally stored data while the application is running.

The module also hooks Telegram’s SRPHelper.getX routine, capturing the two-step verification password in cleartext before hashing and storing it for exfiltration. The code provides functions to list or reset sessions, change or confirm a linked phone number, delete an account and lock users out. It can also remove its own session from the victim’s device list, potentially concealing the operator’s access. Ovi stresses that the source code demonstrates these capabilities, not that every action has been successfully performed against victims.

The implant retrieves its control-server address from Redis using the Domain key, optionally selecting a value for a particular channel. It caches the address and can fall back to a hardcoded value, explaining why callback domains differ between builds. Signed JSON beacons report to endpoints under /api/callback/Tg*, while command requests include a device fingerprint and signature and use retries with increasing delays.

Updates and additional code arrive through Alibaba Object Storage Service (OSS) and MinIO. The Telegram module retrieves an update manifest and hooks from designated storage paths, while a contacts.vcf file can supply contact information. The WeChat component subscribes to a Redis channel identified by a device-specific machine ID, with its host and credentials embedded in a child code file.

The WeChat module focuses on account access rather than chat-history collection. Its _2_0_UploadAppLoginInfo command retrieves login identity information, after which the app data can be packaged, uploaded to OSS and used in account cloning. Ovi found no evidence that the examined sample accessed WeChat’s encrypted database.

Ovi tested uCreater on a Pixel 10 Pro running Android 17 and found that its bundled Pine engine fails because of changes to Android’s internal APIs. The latest sample, dated July 29, 2026, still uses the outdated engine. Although this creates obstacles for operators, updating Pine could restore functionality, and other devices remain untested. Ovi also identified five samples that successfully contacted the control server, confirming active deployments targeting Telegram, Telegram-X and WeChat.

Ovi and researcher Jurre discovered the platform’s source code after finding an exposed GitLab server. Other infrastructure was protected by IP allowlists, but this server contained the control platform’s source code, configuration and operational details.

The repositories revealed Spring Cloud services for command dispatch, authorization capture, data collection, backups and message bridging, alongside a Vue-based administration console. Thirteen repositories contained commit histories identifying roughly three dozen developers, with activity timestamps consistent with China time. At least one commit used a corporate email domain associated with Tanzhou, a Changsha software firm.

uCreater’s backend is a rented, multi-tenant platform that lets operators manage infected devices, steal account data and automate contact collection. Kafka, RocketMQ, Redis and Nacos coordinate commands and schedule activity to avoid triggering security controls. The infrastructure runs on Aliyun and Huawei Cloud, with control services and storage hosted in China. Although GitLab records identify developers behind key components, Ovi stresses they are not confirmed operators. The recovered backend did not appear to support Telegram, and some callback domains are no longer active.

Ovi attributes the platform to a vendor in Changsha and Hunan operating through three companies, each linked to a different technical or infrastructure artifact. The reseller model, focus on mobile wallets and theft of authentication codes suggest financially motivated crime, but the researcher presents this as an assessment rather than a proven fact.

The technical findings show that uCreater goes beyond a conventional banking trojan or a tool that merely steals credentials. By embedding code inside legitimate applications, it can manipulate sessions, access account data, collect contacts and potentially take control of messaging accounts. Its rented, multi-tenant architecture also allows different operators to use the same underlying platform.

The scale of the infrastructure indicates a substantial operation, but neither the number of customers nor the number of compromised devices has been established. Likewise, infrastructure overlaps and developer records provide investigative leads, not conclusive proof of who operated the spyware or who was responsible for individual attacks.

“Mapping points to a commercial resale structure, and targeting driven by wallets and OTPs. My assumption is financially-motivated crimeware.” concludes the report.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, newsletter)

Bitdefender finds Midnight Mimosa, preinstalled Android malware on cheap MediaTek phones that fakes ad clicks, drops apps and builds a proxy botnet.

Bitdefender researchers discovered a campaign called Midnight Mimosa involving preinstalled Android malware on low-cost phones from different brands that use MediaTek platforms. The malware is built into the device firmware and may be hidden in different system packages depending on the model. It is already on the phone before the owner turns it on for the first time and cannot be removed.

The malware has system-level privileges, allowing it to install and remove apps, grant permissions and download code from a remote server without the user’s knowledge. This gives its operators control over the infected devices and allows them to use them for different purposes, including building a large botnet. The campaign appears to be mainly financially motivated.

“This scheme is likely designed mainly to generate revenue. The operators carry out ad and click fraud, collect device and installed-app information, and turn infected devices into residential-proxy relay nodes, making them zombies in botnets.” Bitdefender states. “This creates an additional revenue stream, as access to botnets for DDoS attacks is a hot commodity. The larger the botnet, the more money they can charge.”

The money comes from several places. The operators run ad and click fraud, collect device and installed-app information, and turn infected phones into residential proxy relay nodes. Botnet access for DDoS attacks is a hot commodity, and the larger the botnet, the more they can charge.

The system app doesn’t register the fraudulent clicks itself. The revenue comes from cover apps it drops onto the phone, such as real-looking weather, app-lock, note and OCR apps. Those load genuine ads through a legitimate ad SDK, while an invisible window on top registers ads being shown, and the ad network credits the cover app, not the hidden component.

Bitdefender spotted it through behavior, not a signature. A package called com.android.system.lite looked like a core Android component but didn’t act like one: it repeatedly enabled sensitive access, including Accessibility and Notification Access, and silently installed and removed unrelated apps. It had no icon and an app label of just “System”, and its real machinery sat in a native library that only woke up at runtime.

“The investigation began with App Anomaly Detection, a technology in Bitdefender Mobile Security, which flagged com.android.system.lite: a package carrying the name and appearance of a core system component while behaving like nothing of the sort.” continues the cybersecurity firm. “Most mobile security still runs on a single assumption: scan an app, and if it’s deemed clean, it’s safe. Bitdefender’s App Anomaly Detection (introduced in 2023) exists because, in practice, the theory often doesn’t hold up. Apps can sit dormant and turn hostile weeks later, sometimes only if certain conditions are met (targeted malware). Such apps can pass every static check, only to later pull their real payload from a server or cleverly unpack it from native code.”

The first package discovered was only one version of the malware. The same core code was also found in packages named com.android.sys.prot, com.android.sys.gmsprot and com.android.sys.bcprot, with different digital signing certificates. Bitdefender explains that the main threat is not the package name itself, but the malicious code shared by all these versions.

The malware can silently install at least 32 different apps disguised as useful tools, including app lockers, weather apps, file managers, icon tools, OCR tools and audio editors. It gives itself access to Android’s Accessibility, Notification Access and SMS read/write features. Bitdefender did not observe the malware using the notification or SMS permissions, but the operators could activate them when needed. The malware also repeatedly enables and disables these permissions after short periods.

The install trick is neat and nasty. Before dropping a payload app, the malware disables the Google Play Store app, apparently to dodge Play Protect, then re-enables it afterward, and a safety net turns it back on when the user is present so nothing looks odd. It can also record Google Play as the install source for apps that never came from Play, though real Play apps carry a server-side signature block called frosting, and the forged ones don’t have it.

Under the hood, a native library called libeasy.so decrypts a hidden framework, which fetches a remote configuration from a command server disguised as a weather API. The framework then loads further plugins that run the in-process ad fraud and the silent installs, and it can update itself with new code from the server. The plugins and payloads travel as files with misleading extensions, like JARs named .o and APKs served as .png, so a sample examined offline often holds no active payload at all.

The ad fraud is tunable. The plugin shows ads in full-screen activities and overlays nobody asked for, triggered when the screen turns on or by commands from the operator. It marks those surfaces as secure, so they don’t show up in screenshots or screen recordings, and it fires synthetic clicks with daily caps and timing limits to look organic. The cover apps act as peers in an ad mesh, so one app can drive impressions that another app renders and gets paid for.

One payload app, com.mobile.applock.en, is something else entirely: a single-purpose TCP proxy with no ads and no interface that enrolls the phone as a relay node.

“Our insights reveal these payload applications being installed and removed repeatedly on the same devices. This churn helps the operation reduce the length of time a payload remains visible in the app list, rotate hashes, and change the active monetization module, while the underlying system component stays in place.” states the report. “Beyond generating revenue for operators, the devices can be turned into residential-proxy relay nodes, essentially becoming part of botnets and potentially helping launch DDoS attacks when called upon.”

It connects to a control host over raw TCP on port 6000, rotates across four domains, and pipes traffic between the controller and whatever target the server names. Bitdefender notes an erratum here: the IP it first reported as the control server turned out to be a sinkhole, not a command server.

The campaign relays on Google Play to target Android users. Thirteen apps published there talk to the same servers, under at least two developer accounts and thirteen different signing certificates. They passed Play review, they provide some real function, and they also show ads outside the app, sometimes while the phone sits idle. They don’t have the privileges of the preinstalled packages, but Bitdefender calls them dangerous anyway.

Scale is large. Over roughly two years, the family showed up on thousands of unique devices in more than 150 countries, led by Mexico, France and Italy, followed by the United States, Germany, Brazil and Spain. Two separate regional centers with a long tail behind them is what hardware moving through international online marketplaces looks like, not a single carrier’s channel.

“As we mentioned earlier, Zediel-signed firmware is not the only way malware is shipped. The operators use many other devices, most of them likely visual clones of real phones, to embed the same malware.” states the report. “Beyond the generic user agent strings, many of the affected models are counterfeit devices that borrow flagship names they have nothing to do with. Fake iPhones include: “i17 Pro Max”, “i16_Pro_Max”, or “17_Pro_Max”, and an “iPadAirPro” for the tablet line.“

The phones are often fake models. Some report names such as “i17 Pro Max,” “S25 Ultra” and “Note 18 Ultra,” even though these models do not exist. Others use fake codes that make them look like real Samsung devices. The two most common models are from budget brands: Doogee’s S200 X and Cubot’s KINGKONG X. A public discussion on the XDA forum also describes users finding a hidden com.android.sys.* package that returned under a different name after they removed it.

Who installed the malware? Many affected phones use firmware signed with certificates linked to Shenzhen Zediel. Bitdefender confirmed that these certificates were used to sign firmware on affected devices, but it could not establish how the malware got there or whether the certificate owner knew about it. Other infected phones do not use Zediel-signed firmware, so the malware could have been added by a device manufacturer, a firmware integrator, a logistics partner or another party in the supply chain.

The activity also has a longer history. Bitdefender linked the malware’s infrastructure, through shared domains, to Dr.Web’s Android.Joker family in 2021 and its Android.Phantom and Click families in 2025. The operation now also includes residential proxyware. For defenders, the key is to detect the malware’s core code and command server, and to monitor its behavior. Blocking specific package names is not enough because the attackers can easily change them.

Clearing an infected phone isn’t something an owner can do by uninstalling, because the root component sits in the system partition. It takes firmware-level cleanup or disabling the component over ADB, and neither is realistic for most people who own these phones. The durable fix sits with the vendors and marketplaces that ship and sell the affected firmware.

The two defenses users rely on, store review and the ability to uninstall, don’t apply here, which is why Bitdefender calls preinstalled malware a different threat class.

Users cannot rely on app store checks or simply uninstalling the malware. Bitdefender considers preinstalled malware a separate category of threat for this reason.” concludes the report. “Preinstalled malware is a different threat class. Every user-facing defense assumes the owner is in the loop at installation: the install prompt, the store review, Play Protect, and the ability to uninstall afterwards.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, preinstalled Android malware)

RatHat combines AI-driven screen control, Android debugging abuse and advanced credential theft to give attackers deep control of infected phones.

RatHat is the new Android trojan you should know about. Zimperium researchers just published a breakdown of a strain they’ve traced to China-based operators, and what makes it different isn’t the credential theft, which is standard fare by now. It’s what it does to get there.

It starts the way most mobile fraud does: a text message or a shady ad pointing to a fake app store. Once someone installs the APK, the malware doesn’t just ask for permissions and hope.

“RatHat is primarily distributed through deceptive phishing sites promoted via malvertising, smishing campaigns, and third-party forums, luring victims into manually downloading malicious APKs that appear to be legitimate apps” reads the report published by Zimperium.

The dropper hides its payload in two encrypted files. Both use the same simple decoding process: skip a 24-byte header, read the data length, apply a basic XOR and subtraction operation to each byte, and then decompress the result with Gzip. The second stage is a DEX file loaded directly into memory through reflection. It contains the code needed to unpack and install the final malware.

The droppers also abuse native Android SessionInstaller APIs to get around restrictions on app installation and Accessibility Services, allowing the malware to install its payload and access protected APIs.

RedHat uses four anti-analysis techniques. First, it modifies the ZIP container in ways Android ignores but tools such as unzip and apktool cannot handle correctly. Second, it uses a 61 MB AndroidManifest.xml containing unusual data blocks that can make analysis tools crash or run out of memory. Third, the DEX code contains invalid pseudo-instructions that break disassemblers even though Android can still run the app. Finally, strings are encrypted using StringFog and an additional custom scheme that swaps bytes and applies a 16-byte XOR key.

The malware also checks for debuggers, ptrace, debug settings, Frida, Xposed, root indicators and emulators, making analysis much harder.

The malware first tries to gain access to Android’s Accessibility Service. It then uses that access to silently enable Developer Options and Wireless Debugging on the victim’s phone. It doesn’t need a second device, a cable, or a user to manually approve a USB debugging connection.

This is the most interesting part of the attack. RatHat uses the same Accessibility Service to read the ADB pairing code directly from the phone’s screen. It then pairs with the phone’s own debug interface without any user interaction. In simple terms, the malware tricks the phone into giving itself control.

The malware then places two disguised native binaries in /data/local/tmp. Both are written in Go. One, liblocal-service.so, works as a shell command tool and handles persistence, battery settings and permission changes that are not visible in the main app code. The other, libmedia_codec.so, is a modified FRP reverse-proxy client. Its role is to create a tunnel that lets the attacker connect remotely to the phone’s ADB shell from anywhere on the internet.

The credential theft itself runs on three tracks. There’s a standard Accessibility-based keylogger reading text fields, a second component scraping URLs straight out of browser address bars, and then something considerably more interesting: a hardware-level keylogger running from that same ADB shell, reading raw touch coordinates off /dev/input. Paired with a JSON file mapping out keypad layouts for every major phone brand, a screen tap becomes a digit. It’s a workaround for FLAG_SECURE, custom keyboards, and lock-screen protections all at once, because none of those defenses touch the input driver itself.

On the banking side, RatHat serves fake overlays on top of real banking and payment apps, WeChat and Alipay included, to grab PINs and login credentials while the person thinks they’re using the real interface. Combine that with SMS interception for 2FA codes and you’ve got full account takeover without the victim noticing anything unusual happened.

RatHat serializes the phone’s live Accessibility tree into XML and sends it to a mainstream generative AI assistant, which returns screen coordinates and text so the malware can decide where to tap next. The report puts it plainly:

“Generative AI UI-Automation Engine: This is a particularly unique feature.” continues the report.”The malware serializes the device’s live Accessibility tree to XML and communicates with one of the world’s most popular Generative AI assistants (Figure 4). This AI is used for non-malicious actions including:

• Resolving a named target’s centre coordinates on the screen as JSON to direct synthetic clicks.
• Resolving a target’s actual on-screen text from the XML (without translating).
• Signaling automatic navigation commands like SCROLL_DOWN.”

That single change is what separates RatHat from a decade of scripted Android RATs. Old-school automation breaks the moment a button moves or a layout changes on a new OS version. An AI reading the screen in real time doesn’t care. It just looks and taps, the same way a person would.

Persistence is where things get properly ugly. Uninstall the app and it throws up a fake Google Play error to cancel the removal. Manage to force it through anyway, and the Go agent running outside the app’s lifecycle notices, silently reinstalls the APK, and re-grants every permission, accessibility included, without a single tap from the user. As the researchers describe it:

RatHat uses several communication channels to maintain control of infected Android devices and steal data. The app registers with its C&C server over HTTP and keeps a WebSocket connection open for real-time communication. A separate Go-based agent runs a local server and uses a disguised FRP component to expose it to the internet, allowing attackers to bypass NAT and firewall protections. The C&C infrastructure can receive credentials, SMS messages, files, app lists, lock-screen data and logs, while sending commands, updates, screen-monitoring tools and other components to the device.

There is still an important weak point: the attack needs Accessibility Service access to get started. That makes a basic security rule more important than ever: don’t give Accessibility permissions to apps that have no clear reason to use them, even if the app provides a convincing explanation.

“RatHat’s multi-tiered architecture, reliance on out-of-lifecycle daemons, and use of real-time GenAI decision loops illustrate why traditional, signature-based mobile security controls are insufficient.” concludes the report.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, RatHat)

Google has patched a high-severity zero-day in the Pixel cellular modem after finding evidence that the vulnerability was exploited in limited, targeted attacks.

Google has released its September 2026 Pixel security update, addressing a large set of vulnerabilities, including a high-severity flaw, tracked as CVE-2026-58704 (CVSS score of 8.0), in the cellular modem that has already been exploited in the wild.

“In Cellular Modem, there is a possible permission bypass due to a logic error in the code. This could lead to remote (proximal/adjacent) escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.” reads the advisory.

The vulnerability is an elevation-of-privilege issue caused by a permission bypass resulting from a logic error in the modem code. Google said there are indications that the flaw may have been used in “limited, targeted exploitation.”

“There are indications that CVE-2026-58704 may be under limited, targeted exploitation.” states Google.

As usual, the IT giant has not disclosed who exploited the vulnerability, how many devices were targeted, or what the attacks were designed to achieve.

The vulnerability is particularly notable because it does not require user interaction. According to the CVE record, exploitation can result in remote, proximal or adjacent privilege escalation without requiring additional execution privileges.

The technical details suggest that an attacker able to reach the vulnerable modem environment could exploit the permission bypass to obtain higher privileges. The attack vector is classified as adjacent rather than broadly Internet-facing, an important distinction when assessing the practical exploitation requirements.

The flaw resides in a critical component of moder architecture. Unlike vulnerabilities affecting applications or higher-level Android components, CVE-2026-58704 resides in the cellular modem, a security-sensitive component responsible for communications between the device and mobile networks.

Modem vulnerabilities have historically attracted attention because they can operate below much of the Android application security model. They can also provide attackers with a path toward privileged access without relying on conventional malicious applications or phishing.

In this case, however, Google has not publicly described the complete attack chain. There is also no evidence in the company’s advisory identifying the operation as the work of a commercial spyware vendor or a specific state-sponsored group.

The limited-targeted nature of the exploitation is nevertheless notable.

It suggests that exploitation was not necessarily widespread and may have been directed at a small number of selected devices. Without additional information from Google or independent researchers, the targets and objectives remain unknown.

CVE-2026-58704 is only one of many vulnerabilities addressed by Google’s September Pixel release.

Google’s official Pixel bulletin lists additional security issues affecting components including the kernel, modem, bootloader, telephony stack, Trusted Execution Environment, GPU, Bluetooth, NFC, pKVM and several proprietary Pixel components. The bulletin includes multiple critical-severity vulnerabilities, including remote-code-execution flaws affecting the IP Multimedia Subsystem, libpixelimsmedia, VPU, modem, telephone and BigOcean components.

The broader September Android security bulletin also addresses additional vulnerabilities across the Android platform. Google states that devices using the 2026-09-05 security patch level or later are protected against the issues covered by the Pixel bulletin and the September Android Security Bulletin.

Google’s wording is deliberately limited: it says there are indications that CVE-2026-58704 may be under limited, targeted exploitation.

That is different from saying that the vulnerability is being widely exploited.

At the same time, the confirmation that exploitation has occurred changes the risk profile for affected Pixel users. A vulnerability that exists only as a theoretical security issue can be evaluated differently from one for which exploitation has already been observed.

The absence of public attribution also leaves several questions unanswered.

Was the vulnerability discovered and exploited by a private surveillance company? Was it used by a state-linked operation? Was it part of a broader intrusion chain targeting specific individuals?

At this stage, there is insufficient public evidence to answer those questions.

In the past, exploits of this kind have been used by nation-state actors and commercial spyware vendors.

What is clear is that Google considered the issue serious enough to disclose exploitation and include the fix in its September Pixel security release.

Google recommends that supported Pixel devices receive the latest security update. The 2026-09-05 security patch level addresses the vulnerabilities listed in the September Pixel bulletin as well as those covered by the Android security bulletin.

For users and organizations managing Pixel fleets, the exploitation status of CVE-2026-58704 makes timely patching particularly important.

The incident also highlights a broader security reality: the attack surface of a smartphone extends far beyond the applications installed by the user.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Pixel Modem)

Researchers built a WeChat worm that spreads through incoming calls without user action. Tencent has blocked the exploit.

Researchers at Calif created a WeChat worm that can take over an account through an incoming call, even if the victim never answers or touches the phone.

The attack works only when the caller already appears in the victim’s WeChat contacts. Calif reported the flaw to Tencent in July, and Tencent has blocked the exploit for all users. The good news is that researchers found no evidence that attackers used the flaw in real-world attacks, but the case shows how dangerous zero-click vulnerabilities can be.

“Simply by calling a victim, WeWorm can hijack their account and call their friends, spreading from phone to phone.” reads the report at Calif. “If exploited, actors can compromise over a billion phones (or accounts), upending livelihoods and breaking communities worldwide.”

Researchers built a demo WeChat worm that spread between three test phones without requiring any action from the victims. They started with a Pixel 10a and called an iPhone 17e, exploiting the flaw while the phone was still ringing. After taking control of the iPhone, they used it to call another Pixel 10a and compromise that device too. In other words, one compromised account can become the starting point for the next attack.

The exploit works within seconds and gives the attacker full control of the victim’s WeChat account. They can read and send messages, make calls and use the account as if they were the victim. The victim does not need to answer or touch the phone. Even answering the call does not stop the attack. Declining the call blocks that attempt, but the attacker can simply try again later.

The main limitation is that the attacker must already be a WeChat contact. However, compromising one of the victim’s friends could provide a way around that restriction.

“The victim does not need to answer the call, or interact with their phone at all. Even if they do answer, they hear nothing, and the exploit still succeeds. Declining the call stops that attempt, but the attacker can simply try again later, for example, while the victim is asleep.” the researchers explain. “This exploit requires the attacker to be on the victim’s friend list. But that’s not much of a barrier: an attacker can compromise one of your friends first and use their account to reach you.”

Calif published both Android and iOS RCE demos. The firm did not disclose technical details about the issue and will present the full analysis at a conference. For now, defenders have no clear indicators to search for, and users cannot tell if attackers targeted them with a call.

Combined with other Android and iOS flaws, the attack could also lead to full device control.

Researchers say AI helped them find the flaw and build an RCE exploit in about two days. They then built the worm in another week. They argue that AI is making advanced attack capabilities available to less-skilled attackers, increasing the risk of zero-click threats.

Researchers say the goal of publishing the findings is to raise awareness and encourage governments and technology companies to work together on AI security.

The WeChat flaw comes from a memory corruption bug in the app’s VoIP system. Researchers are keeping the technical details private for now and plan to present their full analysis at a future security conference.

The team believes this bug is just one example of the unusual attack surfaces found in messaging apps. They are researching similar weaknesses in other apps and working with developers to reduce these risks. Some changes may require cooperation from platform owners. Once the work progresses, they plan to publish more details about the WeChat flaw.

In August, Tencent released versions Android 8.0.77 and iOS 8.0.76 that addressed the issue.

WeChat is Tencent’s messaging and social platform, launched in 2011 and now much more than a chat app. It lets users send messages, make voice and video calls, create group chats and share content through Moments. It also includes official accounts, video channels, games, search and Mini Programs, which provide services such as shopping, bookings and deliveries without requiring separate apps.

In China, its local version, Weixin, also integrates Weixin Pay for mobile payments. Tencent reported 1.418 billion combined monthly active users for Weixin and WeChat at the end of 2025, making the platform one of the world’s largest messaging ecosystems.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, mobile)