The companies argue that the law, due to take effect in 2027, interferes with free speech, overrides parents’ decisions, and conflicts with federal protections for online platforms.
AB 1709 prohibits covered platforms from providing California users under 16 certain
“psychologically exploitative features intended to maximize engagement that foreseeably lead to compulsive use.”
The law specifically includes personalized “addictive feeds” and autoplay. It also allows the attorney general to define additional features through regulations.
It would not ban children from using the platforms. They can keep their accounts if the platform removes the restricted features. Otherwise, the platform must delete the account and associated personal information.
The law also requires age verification before providing the restricted features. The law doesn’t stop children from searching for videos, following creators, or communicating privately. It makes exceptions for certain search-based results, content that a user explicitly requests, and direct private messages, subject to conditions.
California’s argument is that harm is not limited to what children see. It can also arise from how a service encourages them to keep using it, through personalized recommendations and features such as autoplay.
The idea behind the law is straightforward: Instead of relying entirely on teenagers to recognize when to stop, require platforms to remove some of the mechanisms designed to keep them engaged.
The companies’ objections
The companies’ objections fall into several related categories.
Meta argues that deciding which posts to show, and how to arrange them, is protected editorial judgment under the First Amendment. Its complaint accuses California of attempting to appoint itself the
“editor, curator, and controller of online speech.”
TikTok makes a similar argument about its For You feed. It says selecting and arranging videos creates a curated product protected by free-speech rights, not merely a mechanism that the state can redesign at will.
Google likewise argues that YouTube’s recommendations help users find relevant, appropriate material among its vast collection of videos. It also defends autoplay as useful for watching content intended to be viewed in sequence.
The central disagreement is whether these are harmful product features that California can regulate, or editorial decisions protected by free-speech rights. California describes them as potentially harmful product design; the companies describe them as protected decisions about publishing speech.
The companies also raise parental control. Google says parents are best placed to decide what is appropriate for their families. TikTok points to its existing teen-account safeguards and Family Pairing controls, arguing that the law restricts free expression while taking decisions away from parents. Meta adds that personalized features can help deliver age-appropriate experiences.
The business model
There is also a commercial interest at stake: engagement. How often people return, how long they stay, and how much they interact all matter to the platforms’ businesses.
Meta’s annual report says it generates substantially all its revenue from advertising. It also says that changes to its content displays and product features can affect time spent, user engagement, and financial results. That doesn’t establish why the companies sued, but it helps explain why restrictions on recommendations and autoplay could have financial consequences.
If removing these features leads people to spend less time on a service, it could mean fewer opportunities to show ads. Compliance would also require product and operational changes, such as checking users’ ages and providing a different experience to those under 16.
Youth is the future. Big Tech is very much aware of this. Meta’s annual report identifies youth as an investment priority and describes attracting and retaining users as a competitive objective. Restrictions affecting how young people join and use a platform could affect its longer-term audience strategy, too.
What the future will bring
California is challenging an important part of the attention-based business model. Meta’s annual report warns investors that regulation affecting how it displays content or serves younger users could affect user growth, engagement, and financial results.
And then there’s the matter of age verification. The required age checks could affect adults as well as children: a service must verify users’ ages before providing the restricted features. Depending on how the checks work, this could involve sharing age-related information, raising privacy concerns and creating another opportunity for sensitive data to be exposed in a breach.
If it were up to me, platforms would stop designing for compulsive use, whatever the user’s age. Adults deserve a healthier online experience too. Applying those protections to everyone would also remove the need to check someone’s age before deciding whether they can use these features. Platforms might lose some advertising opportunities, but time spent online should not be the only measure of a successful service.
Scammers don’t need to hack you. They just need you to click once.
.kadence-column484175_1ef361-88 > .kt-inside-inner-col{padding-top:20px;padding-right:20px;padding-bottom:10px;padding-left:20px;}.kadence-column484175_1ef361-88 > .kt-inside-inner-col{column-gap:var(--global-kb-gap-sm, 1rem);}.kadence-column484175_1ef361-88 > .kt-inside-inner-col{flex-direction:column;}.kadence-column484175_1ef361-88 > .kt-inside-inner-col > .aligncenter{width:100%;}.kadence-column484175_1ef361-88 > .kt-inside-inner-col{background-color:rgba(255, 229, 229, 0.83);}.kadence-column484175_1ef361-88 > .kt-inside-inner-col:before{opacity:0.3;}.kadence-column484175_1ef361-88{position:relative;}@media all and (max-width: 1024px){.kadence-column484175_1ef361-88 > .kt-inside-inner-col{flex-direction:column;justify-content:center;}}@media all and (max-width: 767px){.kadence-column484175_1ef361-88 > .kt-inside-inner-col{flex-direction:column;justify-content:center;}}
In this article
Google says Videostrong backdoored 1.3 million certified Android TV boxes and sold criminals access to the botnet.
The takedown disrupted the botnet, but the backdoor remains in infected boxes’ firmware.
Suspect your box? Disconnect it and ask the seller about a fix or replacement.
Most malware needs you to click something. This one came in the box.
Google’s Threat Intelligence Group (GTIG) says it has high confidence that Android device maker Videostrong Technology built and ran the XCPE backdoor for financial gain. Videostrong sold access to criminal affiliates, who loaded their own malware modules onto the boxes.
GTIG found that the backdoor, called x.cpe (or com.oemservice in some builds), sits in the firmware with system-level privileges. If someone uninstalls it, it reinstalls itself from the /oem/ partition when the device reboots. It could also switch off Google Play Protect app verification, allowing it to install more software without asking.
Google says Videostrong got past its compatibility and security tests by loading the malicious code after the device’s first boot. This allowed the devices to remain part of the residential proxy network.
Residential proxy networks rent out ordinary home IP addresses to customers. That makes their traffic appear to come from a legitimate consumer connection rather than a data center. This can help cybercriminals evade IP-based fraud controls and reputation systems.
The problem for users
Here’s what the backdoored set-top boxes could mean for their owners:
Your home internet connection could be used by others. Residential proxy modules routed other people’s traffic through infected boxes and their owners’ home IP addresses.
Ad fraud. Modules generated fake ad views and clicks in the background.
Spying and remote access to your device. Google observed operators capturing live screenshots, injecting keystrokes, collecting account and device information, and opening reverse shells.
More malware. Some affiliate modules were backdoors that could load further modules.
Your IP address could be linked to activity you didn’t start. Proxy traffic can include attempts to guess account passwords, for example, and may make your home IP address appear in connection with that activity.
How to stay safe
Google and its partners took legal action to take down the domains and servers Videostrong used to control the botnet. Google says it has banned Videostrong and its future subsidiaries and affiliates from making certified Android devices, and strengthened firmware integrity checks for certified Android TV devices.
The takedown only cuts the current connection to the malicious servers. It doesn’t remove the backdoor from infected devices, and can potentially be exploited by other criminals. If you think your box may be affected, disconnect it and contact the seller or manufacturer to ask for clean firmware or a replacement. Uninstalling the app won’t remove the backdoor from the firmware.
Google hasn’t published a complete list of affected models, so owners may not be able to tell from the model name alone whether their box is infected. If you decide to replace your box:
Buy from a reputable manufacturer.
Be cautious about “free TV” boxes. We’ve previously reported on Superbox and similar devices.
Be cautious about apps that pay you to share your bandwidth. They can route other people’s traffic through your internet connection.
Stick to trusted app stores and keep Google Play Protect switched on.
Isolate the box. Put TV boxes and other IoT gear on a separate network or VLAN with restricted outbound access. This doesn’t keep the devices themselves safe, but it does keep other devices separate.
Scammers know more about you than you think.
Malwarebytes Mobile Security protects you from phishing, scam texts, malicious sites, and more. With real-time AI-powered Scam Guard built right in.
Google said today it worked with industry partners to dismantle a botnet made up of more than 1.3 million Android TV set-top boxes that ship with malicious software which secretly rents the user’s Internet connection out to strangers and conducts advertising fraud. Experts involved in the takedown say the action is likely to sever the botnet’s access to more than 10 million additional compromised systems, including other Internet of Things (IoT) products such as Android-based healthcare devices and karaoke machines.
A report from the Google Threat Intelligence Group (GTIG) said Google has severed ties with Videostrong Technology Co., a TV box manufacturer in China that GTIG and other industry experts concluded was responsible for including malware that enrolled more than 1.3 million set-top boxes in a botnet dubbed “XCPE” (named after one of the malware’s core code components).
The global distribution of XCPE botnet infections. Image: Google Threat Intelligence Group.
The report said the XCPE botnet loaded the user’s device with software that makes their Internet address available for resale by multiple “residential proxy” services, which allow customers to rent Internet addresses as a way to anonymize their web traffic or spoof their true location. As detailed in several stories here over the past year, residential proxy services are a major source of unwanted and often malicious traffic, including account takeover activity, advertising fraud, and mass content scraping for AI projects.
“Videostrong monetized the backdoor by selling access to criminal affiliates and loading those affiliates’ malware modules onto infected devices,” the GTIG post reads, noting that Google took legal action to take down the domains and servers Videostrong used to control the botnet and install additional malware. “A device manufacturer intentionally infecting their users with malware is an unacceptable breach of trust, and represents a serious risk to those users. Without users’ knowledge or consent, infected devices were offered as a distribution mechanism for a wide array of criminal actors.”
The report notes that while TV boxes made up the the majority of the botnet, the same XCPE malware was found in other Android-based IoT products, including telehealth devices, karaoke machines, and even digital signage systems.
Google said it requires all Android device makers to pass compatibility and security tests to ensure their products don’t harm users, but that Videostrong nevertheless found a way to load their malicious software immediately after a user boots up one of these devices for the first time (Google says it has since addressed that weakness).
The GTIG report calls out a number of residential proxy providers whose software development kits were routinely downloaded by devices infected by the XCPE botnet. Those include AppSalt, also known as Honeygain, which is owned by the Vilnius, Lithuania-based Oxylabs. In October 2026, Oxylabs was relaunched under a new brand called Source, after receiving $130 million in funding from private equity firm Warburg Pincus that reportedly valued the business at $3.6 billion. Oxylabs did not respond to a request for comment.
Another provider linked to the botnet was NetNut, a once sprawling residential proxy company operated by the publicly-traded Israeli company Alarum Technologies. In July 2026, the FBI worked with industry partners to seize hundreds of domains associated with NetNut, saying the company was responsible for operating a separate botnet called Popa that enslaved TV boxes as residential proxies. Other proxy providers named in the GTIG report include EarnFM, Traffmonetizer, Jaguar, LINKFOG, BMW/IPWeb and GaGaNode.
Google’s announcement credits a number of industry partners, including Synthient, a startup that tracks proxy providers. In January 2026, Synthient published research into the rapid spread of the Kimwolf botnet, which at the time was hammering networks worldwide with record-smashing DDoS attacks. Synthient documented how Kimwolf infected millions of Android set-top boxes virtually overnight, using a widespread vulnerability in these residential proxy services to compromise other Android-based devices inside the local networks of unsuspecting TV box users.
Synthient’s research caused dozens of residential proxy providers to patch their networks, which helped to fragment the Kimwolf botnet into much smaller pieces that made its incessant and disruptive DDoS attacks far easier for network operators to manage. It also attracted the attention of the Motion Picture Association (MPA), a trade group representing the major Hollywood studios, which partnered with Synthient to purchase and tear apart a number of popular Android TV set-top boxes — including some that were being infected by Kimwolf and other IoT botnets.
In a report published today, Synthient examined a popular, pre-infected TV box sold under the brand MECOOL by a publicly traded company in China called Skyworth Technology, concluding that MECOOL also bundled the malware from Videostrong Technology Co. and likewise installed AppSalt/Honeygain and other proxy components.
The MECOOL storefront and marketing. Image: Synthient.com.
Synthient founder Ben Brundage told KrebsOnSecurity that Videostrong’s malware also distributed software for the proxy service Grass. In our November 2025 story, “Is Your Android TV Streaming Box Part of a Botnet?” we quoted a researcher from Censys who found the popular Superbox TV streaming device bundled Grass’s residential proxy software. We also quoted the Grass founder, who denied any affiliation with the TV box maker.
That November 2025 story noted that Superbox and similar Android TV set-top boxes gain new customers primarily by engaging influencers on Tiktok and other social networks who praise the product’s ability to offer hundreds of (pirated) pay TV streaming services for a one-time fee.
Likewise, Synthient’s report observes that the MECOOL set-top boxes exploded in popularity after the product was mentioned in 2023 by the Youtube channel Linus Tech Tips, which has an audience of nearly 17 million subscribers [Linus Tech Tips said in a statement shared with Synthient that it has since updated the video to explicitly frame the product as a scam and have removed all associated affiliate links].
The popular Youtube channel Linus Tech Tips discussing MECOOL TV streaming boxes.
The GTIG report estimates the XCPE botnet takedown should sever access to at least 10 million additional compromised devices, noting that the various proxy and ad fraud affiliates of Videostrong “each have diversified distribution channels for their modules beyond XCPE.”
Synthient’s Brundage echoed that conclusion, calling the 1.3 million number “highly conservative.”
“The scale of affected devices is likely way higher,” he said. “This is probably the largest operation against backdoored TV boxes that we’ve seen.”
Not every risky email should be blocked outright. Some messages may be legitimate but still deserve extra scrutiny. Until now, email security has largely followed a simple model: a message is either delivered or blocked. While this works well for clearly malicious emails, many modern attacks operate in a gray area where the risk is real, but not high enough to justify rejecting the message.
Google has now suspended submissions to its Open Source Software Vulnerability Rewards Program (OSS VRP) after being flooded by AI-generated reports. [...]
Google's Gemini could soon access any file on your macOS device, open apps, browse the web, and perform actions without asking for permission every time. [...]
On September 15 this year, Google published details of patches for 110 vulnerabilities in its own Google Pixel smartphones. Among all the disclosed flaws, CVE-2026-58704 stands out the most, for it appears that this zero-day is being exploited in targeted attacks.
In today’s post, we talk about what’s so special about the Google Pixel, and why these devices get security updates all of their own – separate from regular Android updates. We also cover the vulnerabilities addressed in this latest update, with a special focus on the mentioned, most dangerous one – CVE-2026-58704 – and wrap up with tips on how to both protect your device and avoid becoming a victim of cyberattack on it.
Why do Google Pixel phones get security updates separate from Android?
The reader might reasonably wonder: I’ve already installed this month’s Android security updates on my Google Pixel. Isn’t that the same thing? Google Pixel does run on Android and receives those security updates, which are detailed in the monthly Android Security Bulletin. However, manufacturers of Android-based devices use different sets of hardware and software components. That’s why, alongside vulnerabilities common to all Android devices, there are security issues specific to individual manufacturers’ devices.
For its own smartphones, Google publishes separate security updates, covered by a dedicated Pixel Update Bulletin. Rather than replacing the Android Security Bulletin, this document complements it by detailing vulnerabilities specific to devices manufactured by Google. Other Android smartphones also receive similar updates from their manufacturers.
The Pixel Update Bulletin for September 2026 clearly shows why Google needs separate updates for its smartphones in the first place. Many of the vulnerabilities it fixes affect specific Pixel hardware (or hardware-related) components: the modem, bootloader, GPU, fingerprint scanner components, and other parts of the device. On smartphones from other manufacturers, these features might rely on entirely different hardware and software components, so the fixes listed in the Pixel Update Bulletin don’t apply to those phones.
That said, these vulnerabilities could still be relevant for Pixel owners who’ve flashed their devices with custom ROMs. Switching to a different OS doesn’t alter the device’s hardware components, and may not replace the firmware. Therefore, the vulnerabilities themselves may persist, but whether patches are available, and how they’re installed, depends on the specific OS.
CVE-2026-58704: a zero-day vulnerability being actively exploited in the wild
Now let’s look closer at the specific vulnerabilities Google fixed in September. The most significant one is the above-mentioned CVE-2026-58704.
This vulnerability affects the Cellular Modem component, which handles the smartphone’s communication with cellular networks. It stems from a logic error in the code, which, under certain conditions, allows bypassing the intended permission check.
Successful exploitation of CVE-2026-58704 lets attackers escalate privileges on the smartphone to gain broader access to its functions and data. Note that the attack takes place over a cellular network and the threat actors need low-level privileges on the targeted device to start with.
In practice, this means attackers can’t exploit CVE-2026-58704 to attack a Pixel from just anywhere over the internet, as they’d apparently need to either compromise the cellular network the target smartphone is already connected to or, more likely, force it to connect to a malicious base station under their control.
Google hasn’t disclosed all the details of this vulnerability yet, and the related report is not publicly accessible. As a result, the technical details that would show how easy it is for attackers to exploit CVE-2026-58704 remain unknown pending installation of the patches on all devices.
Nevertheless, Google claims that there are signs of limited exploitation of CVE-2026-58704.
What we know about the other 109 vulnerabilities
Of the remaining 109 vulnerabilities found in Google Pixel devices, only one is rated moderate; the others are either high (62) or outright critical (46). Nine of these flaws fall into the RCE (remote code execution) category. This means that if an attacker successfully exploits one of these vulnerabilities, they can remotely force the device to run malicious code. The exact conditions for the attack depend on the specific vulnerability.
Another 88 vulnerabilities fall into the elevation of privilege (EoP) category. These let an attacker who’s already gained a certain level of access to the device expand their privileges. The CVE-2026-58704 vulnerability discussed above falls into this same category, which is why the September bulletin lists 89 EoP vulnerabilities in total.
Finally, 10 vulnerabilities can lead to information disclosure (ID), and two more to denial of service (DoS). In short, that’s a hefty list of flaws, so Google Pixel owners shouldn’t wait around to install the patches.
How to avoid becoming a victim
Google Pixel owners can install the update that fixes the vulnerabilities covered in this post by following this path: Settings → Security & privacy → System & updates → Security update → Install. Keep in mind that the phone will automatically restart to finish installing the update.
To keep your phone secure we recommend the following general measures:
Install security updates on your phone regularly and promptly – whether it’s a Google Pixel, an Android smartphone from a different manufacturer, or even an iPhone.
Avoid installing apps from questionable sources.
Read reviews before installing apps from official stores, since malware isn’t uncommon there too. Users who have already been burned will often sound the alarm in the reviews long before store moderators get around to removing the dangerous app.
Install a reliable security solution to keep you from downloading malware, and warn you about suspicious activity on your device.
In 2026, the owner of an ordinary home router, smart TV, or TV box is a prime target for cybercriminals. These devices are readily recruited into botnets and residential proxy networks, which we’ve covered before.
Criminals “sublease” the infected device by letting outsiders pay to visit any website from the victim’s IP address, so it looks like the device’s owner is doing it. The service is in demand across all kinds of shady schemes: from ad fraud and spam campaigns to password bruteforcing and account hacking. In our previous post, we described how home routers get recruited into these proxy networks; today we take a look at an even more vulnerable, and equally ubiquitous category of devices: smart TVs and TV boxes.
These appeal to criminals for two reasons. First, unlike computers and smartphones, TVs are almost always plugged into the power and have a fast internet connection. A dark screen doesn’t mean the device is switched off. On top of that, the limited user interface and monitoring tools mean suspicious background processes can easily slip unnoticed past users.
The threat is evolving and growing more aggressive. A recent study found that once proxyware turns up on a set-top box, the risks to its owner go well beyond having their traffic siphoned off.
SuperBox’s marketing leans heavily on the promise of providing thousands of TV channels, with no subscription or monthly fees. But out of the box, the device can’t actually do anything of the sort. To get access to pirated content, you need to install the brand’s proprietary app store.
When you launch it and install additional apps, the thousands of TV channels do appear. Meanwhile behind the scenes, with no warnings or permission prompts, the device floods external sites with unauthorized requests, and network traffic spikes sharply.
The researchers uncovered several alarming facts. First, the victim gets enrolled into as many as five botnets at once. The SuperBox runs clients for several proxyware networks simultaneously, which even try to compete with one another by blocking rival software from being installed.
But the real shock was the attacks on the internal network. The TV box’s proxyware places no limits on what its paying clients can actually do on the network. They can reach not only external sites but also devices inside your home network.
Normally, your home router and ISP settings protect you from outside attacks. But proxyware bypasses these barriers because it operates from inside the network. During an experiment, the researchers confirmed that an attacker on the internet can easily leverage the infected set-top box to open the admin panel of a home router, such as a Linksys, which is supposed to be accessible only to its owner when connected to the home Wi-Fi network. This means hackers can try to steal data from other devices in the same household, or even encrypt home network storage (NAS).
At the same time, flaws in SuperBox’s factory firmware let hackers remotely install and run any application with superuser privileges, and the threat is anything but hypothetical. Over three weeks of monitoring, the test set-top box was hit by more than 1300 attacks through the home proxy network. Attackers installed three different types of malware, including a module for launching DDoS attacks.
The malware uses several methods to gain a foothold in the system, and it survives reboots and power failures alike.
How to tell if your set-top box is working for hackers
If you have a cheap TV set-top box or Android TV from a little-known brand, it’s worth checking it for anomalies.
The most reliable method is to review the network traffic. Use the statistics in your router’s control panel, but note that some budget models may lack this feature. This feature is called Traffic Analyzer on Asus routers, Traffic Usage on TP-Link, and Traffic Monitor on Keenetic. Find your TV or set-top box in the device list and check the ratio of downloaded to uploaded data. They should consume a lot of traffic to download video while sending very little. If your box is quietly pushing gigabytes of data out or staying chatty on the network even while idle, that’s a telltale sign it’s infected.
If traffic statistics aren’t available, look for indirect signs:
The network and memory activity LEDs won’t stop blinking even though no one’s using the device.
The set-top box’s casing is constantly warm or hot.
The interface lags behind the remote, and the box freezes at random moments that have nothing to do with heavy video playback.
Your other devices (computers or phones) are seeing a real drop in internet speed.
When trying to visit familiar sites over your home Wi-Fi, you’re constantly hit with a CAPTCHA — a sign your network may be compromised and flagged as a spam source.
Your ISP’s tech support calls you asking about suspicious network loads.
What to do with an infected device
The best solution is to disconnect the device from the internet and dispose of it. If you have to keep using it, follow these steps to minimize the risks:
Do a factory (hard) reset. Restore the set-top box to its original state.
Take it offline before setting up again. The first time you turn it on after a reset, skip the Wi-Fi setup step and don’t plug in the Ethernet cable.
Block app installation. Go to Android settings and disable installation of apps from unknown sources. Be sure to turn off any debugging features if enabled: USB debugging, Wireless debugging, and ADB. Menu item names may differ depending on your Android version and device manufacturer.
Isolate it on the network. Set up a guest Wi-Fi network on your router and connect the TV box to it. Enable Client Isolation in your router’s settings, if it has it. This will stop the box from seeing other devices on your home network, which protects your computers and network storage.
Check for updates. Once the box is connected to the guest network, check for official firmware updates: manufacturers sometimes patch known vulnerabilities, though with lesser-known brands, you shouldn’t count on it.
Your most reliable safeguards
Buying cheap devices with pirate streaming features and installing software from shady sources is a surefire way to compromise your home network. Your IP address will become a source of malicious activity, which at best gets you blocked by your ISP and at worst puts you on law enforcement’s radar. What’s more, hackers can use the box as a launchpad to attack your home computers and NAS, which can lead to personal data theft or a ransomware attack.
The best protection is to buy devices from trusted brands and pay for legal content. And to rule out someone hijacking control of your network, make sure your router’s admin panel and other home devices are protected with unique, strong passwords. To avoid having to remember them all, use a reliable password manager such as Kaspersky Password Manager. Additionally, the Smart Home Monitor feature included in Kaspersky Premium lets you keep all your devices fully under control.
There may be more things you don’t know about your smart home devices:
Cybersecurity researchers have discovered a new family of Android malware, and it goes by the name of Manic. It lets criminals spy on their victims, steal banking credentials, and take remote control of infected devices.
But its most unusual trick is this: Manic can send stolen data back to attackers even when the given device has no internet connection. Apparently, random mobile internet outages seem to get in cybercriminals’ way just as much as anyone else’s, so the actors behind Manic came up with an unusual workaround.
Researchers haven’t yet pinned down exactly how attackers are getting Manic onto people’s devices. Typically, malware like this spreads through channels like:
Infected apps on legitimate app stores
Malicious APK files shared on pirate websites
Download links sent through messaging apps and email
Scam sites
Google has told journalists it hasn’t found any trace of Manic spreading through apps on the Google Play Store. That suggests people are most likely installing infected apps from unofficial sources.
Experts have traced the beginnings of the attackers’ infrastructure for this campaign to February 2026. The earliest samples of the malware itself turned up in late May of this year. Since then, the criminals behind the Trojan have refined the ways it hides from detection on a victim’s device.
Manic currently combines the powers of a banking Trojan, spyware, and a remote-access tool that lets an attacker control the device. Attackers are especially interested in data from sources like:
Banking apps and payment services
Official government apps
Crypto wallets and cryptocurrency exchanges
Two-factor authentication apps
Text messages and notifications: mainly the one-time codes used to verify logins or approve transactions
By looking at which banking apps Manic targets, researchers have been able to work out which countries it has in its sights. It turns out its reach is broad, covering Austria, the Czech Republic, Estonia, France, Germany, Lithuania, the Netherlands, Poland, Russia, Slovakia, Spain, Ukraine, and the United Kingdom.
Stolen passwords, intercepted codes, remote control: what Manic can actually do
Let’s look at exactly what information Manic steals, and how it manages to get it. The malware’s main trick relies on abusing Android’s Accessibility services, a set of built-in features designed to help users with visual impairments. Used as intended, these features are genuinely helpful for people with vision loss. But criminals have long been quietly exploiting the very same tools for their own purposes.
Once a user grants an app permission to use Accessibility services, that app can “see” the text and buttons on the screen, interact with them, scroll through pages, and carry out actions automatically — all as if a user were doing it themselves. Attackers use this to read messages on screen, quietly grant the malware extra permissions, interfere with attempts to uninstall it, switch off security protections, or control other apps without the victim ever noticing.
With Manic, this abuse of Accessibility services is paired with the Trojan’s own advanced capabilities. It can generate an invisible keyboard that overlays the phone’s real one. When a user types their password to log in to a banking app, Manic records exactly which keys they pressed. Then it uses Accessibility services to instantly replay that same keystroke on the actual app keyboard.
Manic generates a transparent capture layer that covers the phone’s keyboard, recording each tap and relaying it to the real keyboard. Source
This means attackers don’t have to build a fake login screen for every single app they want to target. Because Manic works as an invisible layer sitting on top of the genuine app, everything looks and behaves as usual, so a phone owner has no reason to suspect they’re handing over their PIN or password to a criminal.
Manic doesn’t simply log everything a user types, either. It automatically recognizes what kind of information it has just captured and sorts it into categories: passwords, email logins, four-to-six-digit SMS codes, strings of characters that look like crypto wallet seed phrases, and phone unlock codes or pattern locks. Alongside the captured text itself, Manic also records which app it came from, when it was entered, whether the user typed it manually or used autofill, and whether that app is on its hit list.
Manic’s abilities don’t stop at collecting information. Using Accessibility services once again, it also lets attackers take remote control of an infected device. To conceal this activity, Manic can show a black screen or fake a system update.
On top of Accessibility services, the malware also asks for permission to read text messages and notifications. That lets attackers intercept two-factor authentication codes and one-time verification codes before a victim even has a chance to type them into the app.
Put together, this hands attackers not just passwords, banking credentials, and verification codes, but the ability to remotely control the victim’s phone as well.
Even being offline won’t save you from data theft
Manic’s original method for relaying stolen data off the device and back to the attackers deserves a separate mention. Even today, devices get knocked offline more often than people might expect, and Manic’s creators built a workaround specifically for such situations.
Normally, malware like this collects information on the device and sends it straight to a server controlled by the attackers. But what happens when the infected device has no direct internet access, or can’t reach the command-and-control server for some other reason?
In that case, Manic simply stores the stolen data on the device and starts scanning nearby for other infected phones it can reach over Wi-Fi or Bluetooth. If it finds one with internet access, it hands over the encrypted data to that phone, which then forwards it on to the attackers’ server.
But it doesn’t stop there. Data can hop across a chain of infected devices. By default, Manic allows up to four of these relay devices in the chain. If no suitable device is nearby, the data simply stays on the original phone, and Manic tries again later.
How to protect your phone from Manic and other banking Trojans
Android malware keeps getting more sophisticated. That makes it worth remembering — and actually following — a few basic digital hygiene habits for Android phone and tablet users:
Avoid installing apps from unofficial sources.
Don’t grant apps permission to use Accessibility services unless this is absolutely necessary and you understand exactly why they need it.
Install reliable security software on all your devices, run scans regularly, and take its warnings and recommendations seriously. We recommend Kaspersky for Android. Our Android security apps are temporarily unavailable on the Google Play Store, so to install them on an Android device we recommend using an alternative app store or installing the APK file manually from our website. A full step-by-step guide is available in our post, How to install or update Kaspersky apps for Android in 2026.
Malware doesn’t just target smartphones; it feels at home on other Android-powered devices too — from streaming boxes to… cars. Check out the details in our related posts:
Google is changing how some links in its search results work.
Instead of linking directly to the destination, Google has started routing some search result links through opaque google.com/goto?url=... redirects. The url parameter does not show a readable version of the destination but uses a custom, Google-specific encoding.
“We have a long history of deploying technical measures against evolving forms of abuse, and we regularly take steps to protect our services and users.”
Google has not said precisely what abuse the change is intended to prevent. However, the most likely reason is that the redirects are designed to make bulk extraction of destination URLs from Google search results more difficult and costly. Automated tools must now ask Google to resolve each result separately.
Since the rollout has apparently not reached my neck of the woods yet, I had to grab an image from another source.
Image courtesy of seroundtable.com
Some Reddit users find the change ironic: Google built its search business by automatically collecting information from other websites, but is now making it harder for others to collect information from Google.
Other users have complained about the collateral damage to legitimate tools. Rank tracking, SEO auditing, research, archival, accessibility, and alternate-index services may all face the same rate limits and costs as abusive scrapers.
Search results data provider Autom reports that the final destination is viewable only through the redirect response’s Location header. This means bulk collectors must make an additional request for every result.
Security
The first thing that popped into my one-track mind was the security downside. We often tell users to hover over a link before clicking it so they can check where it leads. That advice is less useful when hovering reveals an encoded Google redirect rather than the destination website.
Google still displays the claimed destination above each search result, but users can no longer use the link preview as an independent check.
So, Google, where does this leave our advice? We already tell people not to click Sponsored search results. Should we now tell them to avoid goto?url links too? Or will you give users an easy way to check where a link leads before they click it?
Google is changing how some links in its search results work.
Instead of linking directly to the destination, Google has started routing some search result links through opaque google.com/goto?url=... redirects. The url parameter does not show a readable version of the destination but uses a custom, Google-specific encoding.
“We have a long history of deploying technical measures against evolving forms of abuse, and we regularly take steps to protect our services and users.”
Google has not said precisely what abuse the change is intended to prevent. However, the most likely reason is that the redirects are designed to make bulk extraction of destination URLs from Google search results more difficult and costly. Automated tools must now ask Google to resolve each result separately.
Since the rollout has apparently not reached my neck of the woods yet, I had to grab an image from another source.
Image courtesy of seroundtable.com
Some Reddit users find the change ironic: Google built its search business by automatically collecting information from other websites, but is now making it harder for others to collect information from Google.
Other users have complained about the collateral damage to legitimate tools. Rank tracking, SEO auditing, research, archival, accessibility, and alternate-index services may all face the same rate limits and costs as abusive scrapers.
Search results data provider Autom reports that the final destination is viewable only through the redirect response’s Location header. This means bulk collectors must make an additional request for every result.
Security
The first thing that popped into my one-track mind was the security downside. We often tell users to hover over a link before clicking it so they can check where it leads. That advice is less useful when hovering reveals an encoded Google redirect rather than the destination website.
Google still displays the claimed destination above each search result, but users can no longer use the link preview as an independent check.
So, Google, where does this leave our advice? We already tell people not to click Sponsored search results. Should we now tell them to avoid goto?url links too? Or will you give users an easy way to check where a link leads before they click it?
Project CAV3RN is a modular espionage framework used against targets in Israel. This report expands on two earlier publications: the first was published in June 2026 as part of our Kaspersky Threat Intelligence Reporting service, and the second was published on Securelist the following month, further documenting the framework’s evolving architecture and C2 capabilities.
Continued tracking of this cluster in early August 2026 uncovered several previously undocumented components that expanded the framework’s communication and orchestration capabilities. The main finding is a complex C2 module that uses DNS A-record responses to choose between direct HTTPS and a Google Apps Script relay for each transaction. The same DNS infrastructure can validate and replace the relay deployment ID, allowing the operator to rotate the Google channel.
We also identified the framework’s local broker, which discovers and loads DLL components, routes messages between them, and supports runtime upgrades.
Multi-transport C2 communication module
The communication module, GoogleService.dll, is a 64-bit DLL compiled with Microsoft .NET 8 NativeAOT. Its PDB path is:
NativeAOT data also revealed references to eight source files, including the Direct.cs, FindMode.cs, and Google.cs.
The DLL exports GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate. During initialization, its host (local broker) registers the module’s callback and starts CheckAvailability. After three seconds, the module sends a type-0 frame to the fixed identifier 33A4BA78-E286-4FF2-85EC-7365265F3D93. The broker returns Err1::33A4BA78-E286-4FF2-85EC-7365265F3D93, which the module expects and uses to learn the broker’s name before starting its C2 worker.
C2 packets contain type, cid, and payload fields. Packets of the type icmgdd are processed by the communication module itself, while other types, including broker, are forwarded to the local broker. Within command payloads, _;;_ separates the command from its arguments and _,_ separates individual arguments.
The s_version handler enumerates DLLs under AppContext.BaseDirectory, collects their company names and versions, and appends the communication module’s name/version and the local broker’s name. This inventory is serialized as JSON, XORed with 0xAC, Base64-encoded, and sent as the module’s initial C2 report.
The module supports five internal commands:
Command
Functionality
s_version
Returns the DLL-version inventory described above. The command is executed automatically at startup.
s_config
Returns the active configuration and, when provided with a JSON configuration object, replaces it in memory.
s_enLog
Enables diagnostic logging at the Debug level.
s_deLog
Disables diagnostic logging and sets the logging level to Fatal.
s_write
Base64-decodes and GZip-decompresses provided data before writing it to the specified file path.
The module reads conf.json from the process’s current working directory. If it is missing, the module generates a seven-character client identifier and writes its embedded defaults to disk.
{
"to": "<generated seven-character ID>", // Client ID
"ad": "https://api.studiotikva.com/api/v1/update/check", // Direct C2 URL
"ho": "studiotikva.com", // DNS domain
"gi": "<redacted>", // Apps Script deployment ID
"de": false, // Enable Debug logging at startup
"mi": 120000, // Poll-delay reset after a non-empty response
"ma": 18000000, // Progressive poll-delay cap
"ri": 30000, // Base DNS recovery/error delay, with positive jitter
"ga": "s3criitC0d3/8-)B-,)", // Apps Script relay authentication key
"gu": "https://script.google.com/macros/s/{0}/exec",
"ua": "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31",
"mcc": 50, // unknown
"mtc": 10 // unknown
}
The s_config command can replace these settings in memory but does not update the file. DNS recovery is the exception: a recovered Apps Script deployment ID is written back to conf.json.
Before polling for commands or sending a result, the module performs a DNS A-record query to select Direct HTTPS or Google Apps Script:
The first label combines a three- or four-character uppercase alphanumeric nonce with the current error state: 0 for None, 1 for GIDFailed, 2 for GoogleFailed, and 3 for DirectFailed. Each new transaction starts in state 0.
The exact response 12.19.29[.]30 is treated as a rejection. Other responses are interpreted according to their fourth octet:
Fourth octet
None (0)
GIDFailed (1)
GoogleFailed (2)
DirectFailed (3)
120 (0x78)
Google Apps Script
Direct HTTPS
Direct HTTPS
Google Apps Script
130 (0x82)
Direct HTTPS
Direct HTTPS
Direct HTTPS
Close the transaction (no channel)
140 (0x8C)
Exception
Exception
Exception
Exception
All other values
Google Apps Script
Google Apps Script
Google Apps Script
Google Apps Script
During analysis, valid .m queries returned 12.121.234[.]120, while malformed queries returned 12.19.29[.]30. For example, YCZ2.41414141303030.m.studiotikva[.]com carries state 2, so the final octet 120 selects Direct HTTPS.
CAV3RN DNS control-plane response: the final octet 120 selects the direct HTTPS channel
When Google mode is selected, the module calculates the MD5 digest of its stored deployment ID and compares its first four bytes with the A record returned by <random5>.<hex-ID>.q.studiotikva[.]com. A mismatch causes the module to retrieve a replacement through .p queries: <random5>.<hex-ID>.p.studiotikva[.]com.
DNS-based deployment-ID freshness check
The offset-0 response contains a one-byte length followed by the first three ID bytes. Each subsequent response contributes four bytes. The observed response 74.65.75.102 represents 4A 41 4B 66: a length of 74 followed by AKf. The DLL stops after collecting the declared length and discards the final padding byte rather than requesting offset 76.
DNS recovery of the Google Apps Script deployment ID: the offset-0 response contains the length byte and first three ID characters, followed by four-byte continuation chunks
One initial response and 18 continuation responses produced a 74-character deployment ID, shown redacted as AKfycby46v0DPSEKWYa****dvQ. The .q response 247.188.216[.]122 contains the bytes f7 bc d8 7a, matching the first four MD5 bytes of the recovered value. This is a 32-bit freshness check.
Wireshark capture showing the .p query sequence used for chunked retrieval of the Google Apps Script deployment ID
Google Apps Script channel
When DNS selects Google mode, the module inserts the deployment ID into https://script.google[.]com/macros/s/{deployment-ID}/exec.
Direct GET requests return a decoy page titled My App with the message This application is running normally. C2 polling instead uses an outer POST to Apps Script whose "m":"GET" field instructs the relay to issue a GET request to its upstream server:
POST /macros/s/AKfycbw2Wo4nYIQ*************UxSvjunDmNpeA/exec HTTP/1.1
Host: script.google.com
Content-Type: application/json
{"k":"s3criitC0d3/8-)B-,)","m":"GET","h":{"X-Client-Id":"AAAA000","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31"},"b":null,"ct":null,"r":true}
The request returns a 302 redirect; a redirect-following client subsequently receives a 200 OK serving the response:
Decoding b produces 9/E=; decoding it again produces f7 f1, which XORs with 0xAC to [], indicating an empty task list. An upstream timeout also exposed https://api.studiotikva[.]com/ac, confirming that the Apps Script deployment forwards requests to an actor-controlled backend.
Direct HTTPS channel
When DNS selects Direct HTTPS, the module contacts the configured ad address, https://api.studiotikva[.]com/api/v1/update/check, without using the relay. This occurs when the final octet is 130 (0x82) in the None, GIDFailed, or GoogleFailed states, or 120 (0x78) in the GIDFailed or GoogleFailed states. The endpoint expects the custom X-Client-Id header; requests without the expected header return {"res":"failed"} in its HTTP response.
However, a GET request carrying the correct X-Client-Id value receives a 76-byte body as shown in the following figure:
GET request to the header-gated C2 endpoint and its encoded tasking response
Base64-decoding the response body and XORing it with 0xAC produced the following broker-directed task packet: [{"type":"broker","cid":109,"payload":"002_;;__,_"}]. The broker type instructs the communication module to forward the task to the local broker.
Inter-component DLL broker
The inter-component broker, rnp.dll, is a 64-bit DLL compiled with Microsoft Visual C++. Its embedded PDB path is C:\Users\user\Desktop\Modules\broker-cavern\1.out\rnp.pdb. It masquerades as the RNP OpenPGP library through numerous rnp_* exports, while rnp_backend_string starts the broker.
The broker coordinates the framework’s DLL components. At startup, it creates the BROKER control structure, initializes its message dispatcher, and scans the host directory for DLLs. Components are grouped by CompanyName, and the highest-version candidate from each group is loaded if it exposes GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate.
The directory is rescanned every second, allowing a component to be added or upgraded without restarting the host. Updates require a higher-version DLL under a new path; replacing an existing file in place is not detected.
Loaded components exchange messages through the broker. It locates the requested destination and invokes that component’s callback. Unknown destinations return Err1::<destination>, while unavailable components return Err2::<destination>.
Command
Function
000
Lists loaded component names and versions
001
Lists every DLL path discovered by the scanner
002
Lists each loaded component’s path, name, and version
The 002_;;__,_ task recovered from the Direct HTTPS channel is forwarded by the communication module to this broker, which returns its component inventory. When unloading or replacing a component, the broker calls its IsPrimeNumber export and waits for its worker threads to stop before unloading the DLL.
Infrastructure
Historical records show that studiotikva[.]com was first registered in February 2024. Wayback Machine captures show Wix’s default disconnected-domain page, while passive DNS associated the domain with Wix infrastructure hosted in an Israeli data center. The domain expired in February 2026 and was subsequently re-registered. It may therefore have originally belonged to a legitimate Israeli business and been acquired by the threat actor only after its expiration; the available evidence does not indicate when ownership changed.
The domain was registered again on May 12, 2026, and redelegated on May 19 to ns1.studiotikva[.]com and ns2.studiotikva[.]com, resolving to 144.172.115[.]17 and 144.172.104[.]82. It later hosted a generic “Studio Tikva” website that provided locally plausible cover: “Tikva” (תקווה) means “hope” in Hebrew.
The infrastructure supported authoritative DNS and direct HTTPS C2. The Google Apps Script deployment acted as an application-layer relay; during an upstream timeout, it exposed https://api.studiotikva[.]com/ac, revealing the actor-controlled backend endpoint.
Project CAV3RN continues to evolve, introducing increasingly sophisticated components and communication capabilities. By abusing legitimate services — previously Outlook calendar events and now Google Apps Script — the framework blends its C2 traffic with normal network activity, complicating network-based detection. Given its development pace, modular design, and operational tempo, we assess that CAV3RN will likely continue to expand. We will continue tracking the framework and reporting on its activity in the wild.
Project CAV3RN is a modular espionage framework used against targets in Israel. This report expands on two earlier publications: the first was published in June 2026 as part of our Kaspersky Threat Intelligence Reporting service, and the second was published on Securelist the following month, further documenting the framework’s evolving architecture and C2 capabilities.
Continued tracking of this cluster in early August 2026 uncovered several previously undocumented components that expanded the framework’s communication and orchestration capabilities. The main finding is a complex C2 module that uses DNS A-record responses to choose between direct HTTPS and a Google Apps Script relay for each transaction. The same DNS infrastructure can validate and replace the relay deployment ID, allowing the operator to rotate the Google channel.
We also identified the framework’s local broker, which discovers and loads DLL components, routes messages between them, and supports runtime upgrades.
Multi-transport C2 communication module
The communication module, GoogleService.dll, is a 64-bit DLL compiled with Microsoft .NET 8 NativeAOT. Its PDB path is:
NativeAOT data also revealed references to eight source files, including the Direct.cs, FindMode.cs, and Google.cs.
The DLL exports GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate. During initialization, its host (local broker) registers the module’s callback and starts CheckAvailability. After three seconds, the module sends a type-0 frame to the fixed identifier 33A4BA78-E286-4FF2-85EC-7365265F3D93. The broker returns Err1::33A4BA78-E286-4FF2-85EC-7365265F3D93, which the module expects and uses to learn the broker’s name before starting its C2 worker.
C2 packets contain type, cid, and payload fields. Packets of the type icmgdd are processed by the communication module itself, while other types, including broker, are forwarded to the local broker. Within command payloads, _;;_ separates the command from its arguments and _,_ separates individual arguments.
The s_version handler enumerates DLLs under AppContext.BaseDirectory, collects their company names and versions, and appends the communication module’s name/version and the local broker’s name. This inventory is serialized as JSON, XORed with 0xAC, Base64-encoded, and sent as the module’s initial C2 report.
The module supports five internal commands:
Command
Functionality
s_version
Returns the DLL-version inventory described above. The command is executed automatically at startup.
s_config
Returns the active configuration and, when provided with a JSON configuration object, replaces it in memory.
s_enLog
Enables diagnostic logging at the Debug level.
s_deLog
Disables diagnostic logging and sets the logging level to Fatal.
s_write
Base64-decodes and GZip-decompresses provided data before writing it to the specified file path.
The module reads conf.json from the process’s current working directory. If it is missing, the module generates a seven-character client identifier and writes its embedded defaults to disk.
{
"to": "<generated seven-character ID>", // Client ID
"ad": "https://api.studiotikva.com/api/v1/update/check", // Direct C2 URL
"ho": "studiotikva.com", // DNS domain
"gi": "<redacted>", // Apps Script deployment ID
"de": false, // Enable Debug logging at startup
"mi": 120000, // Poll-delay reset after a non-empty response
"ma": 18000000, // Progressive poll-delay cap
"ri": 30000, // Base DNS recovery/error delay, with positive jitter
"ga": "s3criitC0d3/8-)B-,)", // Apps Script relay authentication key
"gu": "https://script.google.com/macros/s/{0}/exec",
"ua": "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31",
"mcc": 50, // unknown
"mtc": 10 // unknown
}
The s_config command can replace these settings in memory but does not update the file. DNS recovery is the exception: a recovered Apps Script deployment ID is written back to conf.json.
Before polling for commands or sending a result, the module performs a DNS A-record query to select Direct HTTPS or Google Apps Script:
The first label combines a three- or four-character uppercase alphanumeric nonce with the current error state: 0 for None, 1 for GIDFailed, 2 for GoogleFailed, and 3 for DirectFailed. Each new transaction starts in state 0.
The exact response 12.19.29[.]30 is treated as a rejection. Other responses are interpreted according to their fourth octet:
Fourth octet
None (0)
GIDFailed (1)
GoogleFailed (2)
DirectFailed (3)
120 (0x78)
Google Apps Script
Direct HTTPS
Direct HTTPS
Google Apps Script
130 (0x82)
Direct HTTPS
Direct HTTPS
Direct HTTPS
Close the transaction (no channel)
140 (0x8C)
Exception
Exception
Exception
Exception
All other values
Google Apps Script
Google Apps Script
Google Apps Script
Google Apps Script
During analysis, valid .m queries returned 12.121.234[.]120, while malformed queries returned 12.19.29[.]30. For example, YCZ2.41414141303030.m.studiotikva[.]com carries state 2, so the final octet 120 selects Direct HTTPS.
CAV3RN DNS control-plane response: the final octet 120 selects the direct HTTPS channel
When Google mode is selected, the module calculates the MD5 digest of its stored deployment ID and compares its first four bytes with the A record returned by <random5>.<hex-ID>.q.studiotikva[.]com. A mismatch causes the module to retrieve a replacement through .p queries: <random5>.<hex-ID>.p.studiotikva[.]com.
DNS-based deployment-ID freshness check
The offset-0 response contains a one-byte length followed by the first three ID bytes. Each subsequent response contributes four bytes. The observed response 74.65.75.102 represents 4A 41 4B 66: a length of 74 followed by AKf. The DLL stops after collecting the declared length and discards the final padding byte rather than requesting offset 76.
DNS recovery of the Google Apps Script deployment ID: the offset-0 response contains the length byte and first three ID characters, followed by four-byte continuation chunks
One initial response and 18 continuation responses produced a 74-character deployment ID, shown redacted as AKfycby46v0DPSEKWYa****dvQ. The .q response 247.188.216[.]122 contains the bytes f7 bc d8 7a, matching the first four MD5 bytes of the recovered value. This is a 32-bit freshness check.
Wireshark capture showing the .p query sequence used for chunked retrieval of the Google Apps Script deployment ID
Google Apps Script channel
When DNS selects Google mode, the module inserts the deployment ID into https://script.google[.]com/macros/s/{deployment-ID}/exec.
Direct GET requests return a decoy page titled My App with the message This application is running normally. C2 polling instead uses an outer POST to Apps Script whose "m":"GET" field instructs the relay to issue a GET request to its upstream server:
POST /macros/s/AKfycbw2Wo4nYIQ*************UxSvjunDmNpeA/exec HTTP/1.1
Host: script.google.com
Content-Type: application/json
{"k":"s3criitC0d3/8-)B-,)","m":"GET","h":{"X-Client-Id":"AAAA000","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31"},"b":null,"ct":null,"r":true}
The request returns a 302 redirect; a redirect-following client subsequently receives a 200 OK serving the response:
Decoding b produces 9/E=; decoding it again produces f7 f1, which XORs with 0xAC to [], indicating an empty task list. An upstream timeout also exposed https://api.studiotikva[.]com/ac, confirming that the Apps Script deployment forwards requests to an actor-controlled backend.
Direct HTTPS channel
When DNS selects Direct HTTPS, the module contacts the configured ad address, https://api.studiotikva[.]com/api/v1/update/check, without using the relay. This occurs when the final octet is 130 (0x82) in the None, GIDFailed, or GoogleFailed states, or 120 (0x78) in the GIDFailed or GoogleFailed states. The endpoint expects the custom X-Client-Id header; requests without the expected header return {"res":"failed"} in its HTTP response.
However, a GET request carrying the correct X-Client-Id value receives a 76-byte body as shown in the following figure:
GET request to the header-gated C2 endpoint and its encoded tasking response
Base64-decoding the response body and XORing it with 0xAC produced the following broker-directed task packet: [{"type":"broker","cid":109,"payload":"002_;;__,_"}]. The broker type instructs the communication module to forward the task to the local broker.
Inter-component DLL broker
The inter-component broker, rnp.dll, is a 64-bit DLL compiled with Microsoft Visual C++. Its embedded PDB path is C:\Users\user\Desktop\Modules\broker-cavern\1.out\rnp.pdb. It masquerades as the RNP OpenPGP library through numerous rnp_* exports, while rnp_backend_string starts the broker.
The broker coordinates the framework’s DLL components. At startup, it creates the BROKER control structure, initializes its message dispatcher, and scans the host directory for DLLs. Components are grouped by CompanyName, and the highest-version candidate from each group is loaded if it exposes GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate.
The directory is rescanned every second, allowing a component to be added or upgraded without restarting the host. Updates require a higher-version DLL under a new path; replacing an existing file in place is not detected.
Loaded components exchange messages through the broker. It locates the requested destination and invokes that component’s callback. Unknown destinations return Err1::<destination>, while unavailable components return Err2::<destination>.
Command
Function
000
Lists loaded component names and versions
001
Lists every DLL path discovered by the scanner
002
Lists each loaded component’s path, name, and version
The 002_;;__,_ task recovered from the Direct HTTPS channel is forwarded by the communication module to this broker, which returns its component inventory. When unloading or replacing a component, the broker calls its IsPrimeNumber export and waits for its worker threads to stop before unloading the DLL.
Infrastructure
Historical records show that studiotikva[.]com was first registered in February 2024. Wayback Machine captures show Wix’s default disconnected-domain page, while passive DNS associated the domain with Wix infrastructure hosted in an Israeli data center. The domain expired in February 2026 and was subsequently re-registered. It may therefore have originally belonged to a legitimate Israeli business and been acquired by the threat actor only after its expiration; the available evidence does not indicate when ownership changed.
The domain was registered again on May 12, 2026, and redelegated on May 19 to ns1.studiotikva[.]com and ns2.studiotikva[.]com, resolving to 144.172.115[.]17 and 144.172.104[.]82. It later hosted a generic “Studio Tikva” website that provided locally plausible cover: “Tikva” (תקווה) means “hope” in Hebrew.
The infrastructure supported authoritative DNS and direct HTTPS C2. The Google Apps Script deployment acted as an application-layer relay; during an upstream timeout, it exposed https://api.studiotikva[.]com/ac, revealing the actor-controlled backend endpoint.
Project CAV3RN continues to evolve, introducing increasingly sophisticated components and communication capabilities. By abusing legitimate services — previously Outlook calendar events and now Google Apps Script — the framework blends its C2 traffic with normal network activity, complicating network-based detection. Given its development pace, modular design, and operational tempo, we assess that CAV3RN will likely continue to expand. We will continue tracking the framework and reporting on its activity in the wild.
Google is preparing a new Chrome security feature that would block policy-installed extensions from hijacking the New Tab page or changing the default search engine. [...]
Reddit users found that by using a specific Google search query, it was possible to find Claude conversations that users had shared.
This exposed sensitive material, including crypto wallet keys, names, addresses, work notes, and even erotic or otherwise policy-violating chats. Fortune says Anthropic appears to have fixed the Google indexing issue, but the shared links themselves were still live for people who already had them.
The exposure was tied to Claude’s Share feature, which creates a public web link to a snapshot of a conversation rather than leaving it inside a user’s private account. Reddit users found a search query that surfaced many of these shared chats, plus Claude Artifacts (interactive documents, apps, and other content created by Claude) in Google results. Wired reports that this is still true for Bing.
The main risk is that people use chatbots to think through work, health, legal, or personal matters without realizing that a shared link can behave like ordinary public web content.
Anthropic says Claude chats are private by default, and only conversations users explicitly chose to share were affected. But the incident is a reminder that a “share” button on an AI chat can be more like publishing than messaging, especially if search engines can discover the resulting URL.
How to stay safe
The easy way out here is not to share your AI chatbot conversations with anyone, because you could end up reaching more people than you intended.
That’s because it’s harder to stop pages from being indexed than you might expect. And you don’t have those controls aren’t in your hands. The AI provider should take care of that.
To review or stop sharing conversations in Claude, go to Settings > Privacy > Shared chats.
If you’re using an AI service from a social media company, such as Meta AI, Grok, or Gemini), remember that your conversations could be tied to your account—which might contain a lot of personal information.
When using AI, make sure you understand how to keep your conversations private. Many services offer temporary or incognito chats that aren’t saved to your history, but they aren’t a guarantee against bugs, leaks, or data breaches. Only use the share feature when you’re comfortable with anyone potentially seeing that conversation.
Read the privacy policy so you understand how your conversations are stored and shared. If it’s too long, you can always ask an AI to summarise the important points.
Let’s face it, an incognito window can only do so much.
Breaches, dark web trading, credit fraud. Malwarebytes Identity Theft Protection monitors for all of it, alerts you fast, and comes with identity theft insurance.
Reddit users found that by using a specific Google search query, it was possible to find Claude conversations that users had shared.
This exposed sensitive material, including crypto wallet keys, names, addresses, work notes, and even erotic or otherwise policy-violating chats. Fortune says Anthropic appears to have fixed the Google indexing issue, but the shared links themselves were still live for people who already had them.
The exposure was tied to Claude’s Share feature, which creates a public web link to a snapshot of a conversation rather than leaving it inside a user’s private account. Reddit users found a search query that surfaced many of these shared chats, plus Claude Artifacts (interactive documents, apps, and other content created by Claude) in Google results. Wired reports that this is still true for Bing.
The main risk is that people use chatbots to think through work, health, legal, or personal matters without realizing that a shared link can behave like ordinary public web content.
Anthropic says Claude chats are private by default, and only conversations users explicitly chose to share were affected. But the incident is a reminder that a “share” button on an AI chat can be more like publishing than messaging, especially if search engines can discover the resulting URL.
How to stay safe
The easy way out here is not to share your AI chatbot conversations with anyone, because you could end up reaching more people than you intended.
That’s because it’s harder to stop pages from being indexed than you might expect. And you don’t have those controls aren’t in your hands. The AI provider should take care of that.
To review or stop sharing conversations in Claude, go to Settings > Privacy > Shared chats.
If you’re using an AI service from a social media company, such as Meta AI, Grok, or Gemini), remember that your conversations could be tied to your account—which might contain a lot of personal information.
When using AI, make sure you understand how to keep your conversations private. Many services offer temporary or incognito chats that aren’t saved to your history, but they aren’t a guarantee against bugs, leaks, or data breaches. Only use the share feature when you’re comfortable with anyone potentially seeing that conversation.
Read the privacy policy so you understand how your conversations are stored and shared. If it’s too long, you can always ask an AI to summarise the important points.
Let’s face it, an incognito window can only do so much.
Breaches, dark web trading, credit fraud. Malwarebytes Identity Theft Protection monitors for all of it, alerts you fast, and comes with identity theft insurance.
Google heeft aangekondigd dat het ondersteuning voor Android 6.0 Marshmallow stopt. Daardoor worden smartphones met dit besturingssysteem kwetsbaarder voor hacks.
Starting last year, Android users have been seeing the “number is now verified” system notification more frequently. And in some cases people even find mysterious outgoing text messages in their history that they never sent.
These messages often cause confusion and even anxiety: has a virus infected the phone? Are tech giants spying on our phone numbers? Let’s break down how this feature works, and what potential risks it poses to your privacy.
Why all these phone number verifications?
The notification pops up whenever Google’s phone number verification feature is triggered on your device.
Its main job is to make sure that the SIM card tied to a specific phone number is physically inside the phone. Once verified, that phone number automatically links to all active Google accounts on the device.
There are several key services that rely on the verification. Most importantly, it drives Rich Communication Services (RCS) — the modern standard for “rich” messaging right inside your standard text messaging app. It feels like a popular chat app, but without the need to install anything extra. Unlike iMessage, which is locked to Apple’s ecosystem, RCS works across compatible smartphones on various platforms since it’s an industry standard set by carriers rather than tech giants. Since recently, both Apple and Android users have been able to exchange RCS messages. For this feature to work in the Google Messages app, Google needs ongoing confirmation that your SIM card is active. If you pull out your SIM card, RCS chats will keep working for about eight days before turning off automatically.
According to Google, phone number verification serves several other purposes as well:
Account security and recovery. A verified phone number enables quick sign-ins to your Google account, two-factor authentication, and easy password recovery.
Emergency services and device location. This includes Find My Device, remote phone lock, and sharing your location with emergency responders — including via satellite messaging on the Pixel 9 and certain other modern smartphones.
Better sharing on Google. This feature helps other people find you faster on Google Meet or Duo, use Quick Share to send you files, and see that the phone number is linked to your profile.
Google also recently confirmed that this data is used to counter scams. Verification helps block calls or text messages from spoofed numbers if both the real owner of the number and the recipient are using Android devices with verified phone numbers.
How does Google verify phone numbers?
Phone number verification technology has been around on Android for quite some time — Google was sending test SMS messages as far back as in 2019. However, it became widely visible to most users following a Google system update in September 2025. The process was baked deeper into the operating system, with number verification now running by default during initial phone setup, and re-running periodically in the background.
There are two main technical methods for the verification process. Which one your device uses depends on your mobile carrier and your version of Android.
The older method relies on hidden text messages. In the background, your smartphone sends a specialized technical text message to Google’s servers. The operating system intercepts this message before you ever see it, which is why it rarely appears in your standard text messaging app. However, due to software glitches or Android customization quirks, these texts occasionally surface in sent messages, startling users. They typically look like this: “(string of letters and numbers) Google is re-verifying the phone# of this device.” Google explicitly notes in its help documentation that standard messaging rates from your carrier may apply.
In recent years, direct carrier verification (via carrier APIs) has become the primary verification method. This approach is more modern and secure than previous ones. The smartphone sends an encrypted token containing device and SIM card identifiers to the mobile carrier, and the carrier responds with the confirmed phone number. The whole process takes just a couple of seconds and runs completely unnoticed by the user. Both global telecom giants and smaller providers have connected to this verification network. Notably, third-party apps can also tap into the results of this check through Firebase Phone Number Verification, getting confirmation from your mobile carrier about which phone number is active on the device.
“Other device data” and privacy concerns
In its official documentation, Google notes that device identifiers and SIM card data may be collected during verification. In practice, this refers to unique identifiers for the SIM card and its subscriber profile (ICCID and IMSI), as well as technical device identifiers needed to run mobile networks. Google also explicitly states that it does not sell your personal information, including your phone number, to anyone.
Naturally, sending additional unique identifiers to Google — especially given the scale of its advertising business — always raises concern among privacy-conscious users. Here’s what you should keep in mind:
Metadata collection. To run RCS, Google exchanges data with your mobile carrier. Even when the content of RCS messages is encrypted, metadata — such as who is messaging whom and when — can still be stored on your carrier’s servers, and in some cases, on Google’s servers. As cybersecurity experts at the Electronic Frontier Foundation point out, if privacy is your top priority, you’re better off sticking to dedicated encrypted messaging apps.
Linked accounts. If you have both a personal and a work Google account (or a personal and a family account) set up on the same phone, the verified number will automatically link to both profiles. The operating system does not offer built-in tools to separate numbers for different accounts on a single device.
Phone number leaks. Apps on your device can already access various user identifiers, including your phone number. However, this verification system makes it easier to link multiple phone numbers to a user who has multiple Google accounts. And while Google states that it never sells phone numbers, you cannot say the same with confidence about obscure third-party Android developers.
On by default. The feature is enabled out of the box, and most users have no idea their device is silently querying their carrier in the background. While you can opt out in your Google settings once you notice it, there’s no guarantee that any data already collected will actually be deleted.
Turning off verification — why and how
For most users, verification is genuinely helpful. It simplifies account recovery, makes finding a lost phone easier, powers modern text messaging features, and assists emergency services when every second counts.
However, if you want to minimize the amount of metadata sent to Google, mobile carriers, and other data brokers, you can manually disable the feature. Here’s how:
Open your Android smartphone’s settings.
Tap Google, select the account at the top, and switch to the All services tab.
Under Privacy and security, tap Phone number verification.
Turn off automatic phone number verification.
If you also want to disable Better sharing on Google, go to Settings → Google → Manage your Google Account → Personal info → Contact info → Phone, select your number, and turn off the setting.
If you have multiple Google accounts on your phone, you’ll need to repeat these steps for each one. Unfortunately, verification sometimes turns itself back on automatically, and there’s no reliable way to prevent this on standard consumer phones with stock software.
Keep in mind that disabling verification means losing access to RCS chats in Google Messages — forcing you to fall back on basic SMS, or switch to alternative secure messaging apps. You also won’t be able to use that number for quick account recovery should you forget your password.
To thoughtfully customize your privacy settings across all your devices — regardless of the operating system, browser, or app — check out our free online tool, Privacy Checker.
Curious about other privacy risks you might not even know exist? Check out our other deep dives, here:
Login
