Search This Blog
Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Load More
Trendy Right Now

Popular Posts

Showing posts with label Google+. Show all posts
Passkeys
Account Hijacking Chrome Security Google malware Passkeys

Malware Attacks Google-Synced Passkeys

 

Security researchers have uncovered three attack techniques that could allow malware on compromised Windows computers to abuse passkeys synchronized through Google Password Manager. The attacks, collectively called “Pass-ta-key,” target Chrome devices equipped with a Trusted Platform Module (TPM). Rather than breaking the cryptography behind passkeys, the techniques exploit weaknesses in device registration, recovery, user verification, and cloud synchronization. 

Passkeys are widely considered safer than passwords because they cannot be guessed, reused, or easily stolen through phishing. They normally rely on a device-based cryptographic key and may require a PIN, fingerprint, or facial recognition to approve a login. However, Unit 42 researchers found that malware already running on a victim’s computer could manipulate Chrome’s trusted-device mechanisms without requiring administrator privileges or direct user interaction. 

The first technique, Pass-ta-key, abuses Chrome’s TPM-backed device identity key to make Google’s cloud authenticator believe that a request came from the legitimate computer. The service may then return a valid authentication assertion that attackers can use to access a protected account, even without biometric or PIN verification. This attack failed against GitHub because the platform correctly checked the WebAuthn user-verification flag, but it succeeded against eBay before the company fixed the validation issue. 

The second method, Silver Pass-ta-key, enables attackers to register their own verification key during a forced Chrome re-registration process. Malware can invalidate the existing verification state or delete local passkey-related data, allowing the attacker-controlled key to be accepted as proof that the device was unlocked by its owner. The most serious technique, Golden Pass-ta-key, attempts to extract Google Password Manager’s Security Domain Secret from Chrome’s memory. This master key encrypts synchronized passkey records, so stealing it could allow attackers to recover private keys and impersonate the victim from another device. 

Unit 42 said the stolen secret could potentially decrypt both existing and future passkeys because Google’s current implementation reportedly does not provide a method to rotate or revoke it. The findings highlight that passkeys remain resistant to phishing but cannot fully protect accounts when malware controls a trusted device or browser process. Websites should strictly validate user-verification signals, while credential managers should strengthen device enrollment, recovery, re-registration, and protection of encryption keys in memory. Google was notified of the research, although a complete public response or confirmation of remediation was not immediately available.
Read more »
Privacy
Browser Browser VPN Security Chrome Data Cookies DNS Google HTTP Incognito mode ISP Privacy

Google’s Incognito Mode Does Not Make Users Invisible. Here’s What It Actually Protects

 



Google’s Chrome Incognito mode can keep browsing history off a device, but it was never designed to make users anonymous online. A class-action lawsuit over the feature exposed how far that distinction could be misunderstood, with Google agreeing to delete or remediate billions of private-browsing records and change how it explains Incognito to users.

The lawsuit, Brown v. Google, was filed in 2020 and alleged that Google continued collecting information about users while they browsed through Chrome’s Incognito mode and other browsers’ private-browsing modes.

The plaintiffs initially sought billions of dollars in damages, with their claims eventually putting at least $5 billion at stake. However, Google did not ultimately agree to pay $5 billion. Under the settlement, there was no class-wide monetary payout. Instead, Google agreed to data deletion and remediation measures, changes to its privacy disclosures, and additional restrictions on data collection. Plaintiffs’ lawyers valued the settlement’s non-monetary relief at more than $5 billion, with estimates reaching $7.8 billion.

The case nevertheless exposed a fundamental problem with private browsing: preventing a browser from retaining a user's history is not the same thing as preventing websites, network operators or online services from observing that user's activity.


Google employees raised concerns about Incognito

The legal dispute became particularly notable after internal Google communications surfaced during litigation.

In one email, Google Chief Marketing Officer Lorraine Twohill told CEO Sundar Pichai that the company should make Incognito "truly private." She also warned that Google could not market the feature too strongly because it was "not truly private," requiring what she described as "fuzzy, hedging language."

Other internal communications were even more critical of the feature. According to material cited in the litigation, Google employees described Incognito as "misleading" and "effectively a lie," while another employee argued that Google should stop using the Incognito name and its spy-themed icon because users could misunderstand the protection it provided. Another recommendation suggested replacing the messaging with a warning that users were not protected from Google.

These discussions mattered because the lawsuit was not simply about whether Incognito stored browsing history locally. It questioned whether users were being given a sufficiently accurate understanding of what happened to their data after it left the browser.

Google disputed the allegations and maintained that the limitations of Incognito had been communicated to users. A Google spokesperson said the company believed the lawsuit was without merit and argued that Incognito was intended to provide a private browsing experience, rather than prevent websites and services from collecting information.


What Incognito actually does

Chrome's Incognito mode does provide a real privacy function, but that function is primarily local.

When a user opens an Incognito window, Chrome starts a separate browsing session. Once all Incognito windows are closed, Chrome does not retain the browsing history, cookies and site data, or information entered into forms from that session in the normal browser profile. Third-party cookies are also blocked by default in current versions of Chrome, although users can temporarily allow them for particular sites.

This makes Incognito useful in situations where the concern is another person accessing the same device.

Someone using a shared computer, for example, can browse for a gift without leaving the visited pages in Chrome's ordinary history. It can also provide a separate browsing session when a user does not want existing cookies and account sessions to carry over.

But there is an important limitation.

Incognito does not erase everything created during a session. Downloads remain on the device, and bookmarks saved during the session remain available after Incognito is closed. Signing into a website can also allow that service to associate activity with the account being used.

The key distinction is therefore simple: Incognito primarily limits what Chrome stores locally. It does not turn the internet connection into a private tunnel.


Your ISP and network administrator can still see activity

Opening an Incognito window does not prevent an internet service provider from observing network activity.

Google's own documentation states that organizations managing a network, including schools, employers and internet service providers, may be able to observe activity while a user is browsing in Incognito. Incognito also does not hide activity or location from the websites being visited.

This is an important distinction from encryption.

Chrome's HTTPS protections can encrypt traffic between a browser and an HTTPS-enabled website, helping prevent someone monitoring the connection from reading the contents of that traffic. Chrome also warns users when they are about to load sites without HTTPS, while Secure DNS can encrypt DNS lookups in supported configurations.

But HTTPS does not make the user anonymous.

The network still has visibility into connection metadata, while the destination website receives the request and can process information available to it.

In other words, Incognito and HTTPS solve different problems. Incognito reduces local traces. HTTPS protects communications in transit. Neither one, by itself, is an anonymity system.


Websites can still identify and track users

The privacy boundary becomes even clearer once a user reaches a website.

Google's current Chrome documentation explicitly states that Incognito does not change how websites collect data or how the services those websites use collect information. Sites can continue gathering information even when a user is not signed in.

Websites can also use first-party technologies and other mechanisms to understand activity within a session. Third-party cookies are only one part of the tracking ecosystem. Google itself notes that websites can use different mechanisms to personalize content and advertising and learn about activity across sites.

This is also where the distinction between an IP address and browser history matters.

Incognito can prevent a local Chrome profile from retaining the list of pages a user visited. It does not automatically conceal the network address from the websites receiving the connections.

And if a person voluntarily signs into a service while using Incognito, the service has an obvious account-level identifier with which to associate the activity. Google's own documentation warns that signing into a Google service or another website during an Incognito session can allow that site to remember the activity.


The lawsuit forced changes to Incognito

The settlement went further than simply changing a warning message.

According to the court filing, Google agreed to delete or remediate billions of records reflecting class members' private browsing activities. The company also agreed to continue blocking third-party cookies in Incognito for five years.

The filing provides an unusually detailed picture of why the cookie change mattered.

Google had historically collected its own third-party cookies when users visited non-Google websites. After the lawsuit was filed, Google implemented third-party-cookie blocking for Incognito users. Under the settlement, that protection had to remain in place for five years. The plaintiffs' filing said blocking data associated with Google's third-party cookies in Incognito could reduce Google's global annual revenue by nearly $500 million.

Google also agreed to remove four identified private-browsing detection signals. According to the plaintiffs' filing, those signals could reveal that a user had chosen private browsing and were then used to label the resulting data as private. The settlement required Google to delete those signals and agree not to use such detection mechanisms to identify or track private browsing.

The class covered an estimated 136 million users, according to court-related filings.


Google eventually changed the warning

The dispute also changed the language presented to Chrome users.

Chrome's current Incognito documentation now makes the limitation explicit. It says that Incognito does not change how data is collected by websites users visit and the services those websites use, including Google. Google also says that websites, network administrators and ISPs may still be able to observe activity during an Incognito session.

That clarification is arguably more important than the Incognito icon itself.

The familiar private-browsing interface can create an intuitive association between the words "Incognito" and anonymity. Technically, however, the feature is much narrower. Chromium describes Incognito as a window-level mode in which pages are not persisted to browsing history and a temporary cookie store is used for the session.

That is a local privacy mechanism, not an invisibility cloak.


So, is Incognito worth using?

Yes, if the objective is local privacy.

If you share a computer with other people, do not want a particular browsing session stored in your ordinary history, or want a temporary browser session separated from your normal cookies, Incognito remains useful.

It is also useful for testing how a website behaves without the cookies and account state associated with a normal session.

But users should not treat the Incognito icon as a guarantee that their online activity is hidden.

It does not prevent an ISP or network administrator from observing activity. It does not stop websites from collecting information. It does not automatically hide an IP address. It does not prevent a user from being identified after signing into an account. And it does not protect files downloaded to the device after the session ends.

Users seeking stronger privacy need to think in layers rather than relying on a single browser setting.

A privacy-focused browser can reduce tracking at the browser level. Tracker and content blockers can limit third-party collection. A properly configured VPN can conceal the user's IP address from the websites they visit and hide destination traffic from the ISP, although the VPN provider itself becomes part of the trust model. Keeping the browser, operating system and extensions updated remains essential because privacy controls cannot compensate for an unpatched security vulnerability.

Chrome itself should also not be treated as static. Google continues to modify its privacy and security architecture. Third-party-cookie protections in Incognito are already part of the browser's privacy model, while Google has also explored additional protections for IP addresses in Incognito.

The larger lesson from the Incognito lawsuit is therefore not that private browsing is useless.

It is that privacy has layers, and the word "private" can mean very different things depending on where the data is stored, who controls the network and which services receive the user's requests.

Incognito can hide your browsing history from someone checking the same device.

It cannot make you disappear from the internet.

Read more »
User Privacy
Android Chrome Cloud Data Google Internet User Privacy

Google Chrome's New Defense Model to Protect Users Against Malicious Notifications


According to Google, Chrome’s anti-abuse system has decreased unwanted notifications in the first quarter of 2026 by over 7 billion daily on Android.

In a new blog post, Google said that notification exploits have been used to spread malware, scams, fake payment requests, and phishing attempts.

To decrease the exploit, Google made a “Swiss cheese” defense system, where numerous overlapping systems simultaneously try to stop exploit at different levels.

According to Google, "Our goal is to ensure that if abuse slips through one layer, another is there to catch it. This approach allows us to halt abuse at the source, preventing deceptive content from reaching users while maintaining a healthy balance between utility and security."

Automatic notification permission removal by Chrome

Currently, Chrome can already revoke notification permissions from inactive sites, and also from websites that continuously give suspicious-notification warnings.

This can automatically unsubscribe a user from a website’s notification if Chrome removes the permission.

According to Google, users can still see the automatically revoked permissions in Safety Hub and permit access again if they wish to.

Users can also unsubscribe from notifications directly from the notifications panel of Android.

Besides allowing users more control, Google is studying user behaviour throughout networks of associated websites. This includes coordinated service-worker activity, to look out for groups spreading harmful or malicious notifications. 

According to Google, "This enables us to proactively revoke permissions from these persistent bad actors, protecting users from deceptive notifications even when the site content might not seem inherently malicious."

Google analyzes factors including time you spend on a website, engagement, permission-prompt frequency, and notification volume. 

For instance, websites categorized as malicious can be restricted to 1,000 messages per minute, with additional requests showing an HTTP 429 error. These restrictions are reset after a period of non-disruptive behaviour and can be more strict for repeat violators, Google said.

Users can also control notification settings

Chrome has also modified how notification permissions prompts function on Android. Chrome has built a relatively less disruptive interface for users to decide if they want certain notification without poking their browsing. 

"This strategy has substantially decreased unnecessary background activity, reduced user device battery consumption, and transformed the notification lifecycle so users receive only the content they find truly valuable," Google said.

How to turn on settings

For users who want to manually control these settings, for Chrome users, “On Desktop, navigate to Settings > Privacy and security > Site Settings > Notifications, or open chrome://settings/content/notifications in the omnibox,” Google said.

For android, “tap More (⋮) > Settings > Notifications.”

Read more »
Tesla
Alphabet Artificial Intelligence Financial Loss Google Technology Tesla

Alphabet, Tesla Shares Slide as Wall Street Questions Mounting AI Investment Costs

 


Investors wiped billions from the market value of Alphabet and Tesla after the companies disclosed another sharp increase in spending tied to artificial intelligence, signalling that Wall Street is becoming less willing to reward ambitious investment plans without clearer evidence of when those outlays will generate stronger financial returns.

Alphabet's shares fell nearly 7%, while Tesla tumbled 14.5% following the release of their latest quarterly earnings. Although both companies remain committed to expanding their long-term technology capabilities, investors focused on a different figure: free cash flow. Each company reported that the cash remaining after funding operations and capital investments had turned negative, raising fresh questions about the financial burden created by large-scale AI and infrastructure projects.

The reaction illustrates a growing divide between technology companies and financial markets. Executives continue to argue that today's spending is necessary to secure future leadership in artificial intelligence, while investors are looking for clearer signs that those investments will eventually translate into stronger earnings and cash generation.

Alphabet's quarterly revenue climbed to $119.8 billion, a 23% increase from the same period a year earlier, showing that demand across its businesses remained healthy. Yet strong sales did little to ease investor concerns because the company's capital spending accelerated even faster.

For the quarter, Alphabet reported negative free cash flow of $5.9 billion, the first such result since the company became publicly listed in 2004. Free cash flow is closely watched by investors because it measures how much cash remains after a company pays its operating expenses and funds long-term investments. A negative figure does not necessarily indicate financial weakness, but it does show that investment costs exceeded the cash generated during the period.

Alphabet Chief Financial Officer Anat Ashkanazi told financial analysts that the decline was driven almost entirely by AI-related capital expenditure. The company invested approximately $45 billion during the quarter, allocating around 60% of that spending to servers and the remaining 40% to expanding data centre capacity needed to support growing demand for AI services. The latest figure also represents a substantial increase from the $36 billion Alphabet invested during the previous quarter.

The company has now lifted its projected capital expenditure for the year to as much as $205 billion, roughly $15 billion higher than the estimate it provided three months ago. Most of that investment will support AI infrastructure, including computing resources capable of training and operating increasingly sophisticated artificial intelligence models.

Ashkanazi said customer demand for AI products continues to exceed the company's available computing capacity, adding that Alphabet intends to keep investing while opportunities remain attractive.

Chief Executive Officer Sundar Pichai described artificial intelligence as a technological transition that is still in its early stages. He said the company remains disciplined in evaluating where it allocates capital and believes substantial opportunities remain to transform advanced AI capabilities into products and services used by businesses and consumers.

Tesla reported a similar financial picture. The electric vehicle manufacturer posted negative free cash flow of $1.1 billion during the second quarter, its first negative reading in two years, after investment costs climbed across several strategic initiatives.

The company expects capital expenditure to reach as much as $25 billion this year, more than double what it invested during 2025. While Tesla has not disclosed a detailed breakdown of every project included in that forecast, the spending is expected to support manufacturing expansion, autonomous driving technology, robotics, AI development and the computing infrastructure required to power those initiatives.

Tesla Chief Financial Officer Vaibhav Taneja said the company is entering a major investment cycle and expects spending to continue rising over the next three years as those programmes move forward.

Market analysts say the concern is not that technology companies are investing in artificial intelligence, but that the scale of spending has reached levels that demand measurable financial returns. Russ Mould, investment director at AJ Bell, said investors remain sceptical that such unprecedented expenditure will produce returns proportionate to the capital being committed.

Rachel Winter, a partner at wealth management firm Killik & Co, also noted that Alphabet's latest investment plans exceeded many expectations, suggesting the market's response indicates unease about the pace at which those billions of dollars will translate into higher profits.

The earnings from Alphabet and Tesla arrive as the technology industry commits record sums to artificial intelligence. Companies including Microsoft, Amazon and Meta have all expanded spending on specialised chips, cloud infrastructure and data centres to support rapidly growing AI workloads. As competition intensifies, capital expenditure has become one of the defining financial themes shaping the sector.

For investors, however, enthusiasm for artificial intelligence is now accompanied by tougher questions. Revenue growth alone is no longer enough to reassure the market. Companies are now expected to show that record-breaking investment in AI infrastructure can eventually deliver sustainable profits, stronger cash generation and lasting value for shareholders.

Read more »
Manifold
AI Browsers Anthropic Claude Claude Code CVSS Cyber Security Google Manifold

Researchers Find Claude for Chrome Flaws That Could Let Malicious Extensions Trigger Sensitive Google Tasks




Researchers at Manifold Security have disclosed two security weaknesses in Anthropic's Claude for Chrome extension that could allow another browser extension with access to the Claude website to trigger predefined AI-powered actions involving a user's Gmail, Google Docs and Google Calendar.

According to the researchers, the issues remain present in version 1.0.80 of the extension despite earlier mitigations introduced after the disclosure of the "ClaudeBleed" vulnerability. While Anthropic restricted how external webpages can communicate with the extension, Manifold says the underlying trust boundary that determines whether a user intentionally initiated an action has not been fully addressed.

The findings do not indicate that arbitrary websites can directly read a user's email or documents. Instead, the attack requires another browser extension that already has permission to execute scripts on the claude.ai domain. If such an extension is malicious or becomes compromised, it could abuse Claude's existing capabilities to initiate AI tasks that access a user's connected Google services.


Forged clicks can initiate predefined Claude actions

Following the earlier ClaudeBleed disclosure, Anthropic replaced unrestricted prompt handling with a fixed allowlist of predefined onboarding tasks. Rather than allowing external callers to submit arbitrary prompts, the extension now recognizes only nine task identifiers embedded within its code.

Among these are demonstration workflows for third-party services such as DoorDash, Salesforce and Zillow, along with tasks that interact with Gmail, Google Docs and Google Calendar. This design significantly narrows the attack surface because outside scripts can no longer provide custom instructions for Claude to execute.

However, Manifold Security found that the mechanism responsible for launching these tasks can still be manipulated.

The researchers explain that a content script running within the extension monitors the Claude webpage for clicks on a specific onboarding element. When a click occurs, the script reads the associated task identifier and forwards it to the extension, which opens Claude's side panel with the corresponding workflow prepared.

The problem lies in how those clicks are validated. Instead of confirming that the event originated from an actual user interaction, the extension accepts any matching click event, including one generated programmatically by JavaScript.

Modern browsers provide an "event.isTrusted" property that distinguishes genuine user actions from synthetic events created by scripts. According to Manifold, the extension does not verify this property before processing the request.

As a result, another extension capable of interacting with the Claude webpage can dynamically create the required element, assign one of the approved task identifiers and dispatch an artificial click event. Because the extension treats the event as legitimate, Claude opens the selected workflow as though the user had manually initiated it.

The researchers demonstrated this behavior using a short proof-of-concept script executed within the Claude page, showing that synthetic click events marked as untrusted were still accepted by the extension.


Approval settings determine the level of risk

Whether the forged action progresses beyond this point depends largely on how the extension has been configured.

For users operating under Claude's default "Ask before acting" setting, the extension still presents an approval prompt before carrying out actions involving Gmail, Google Docs or Google Calendar. This additional confirmation prevents automatic execution, although users could still unknowingly approve an attacker-triggered request.

The risk increases considerably for users who have enabled the optional "Act without asking" mode. In this configuration, the extension can perform supported tasks without requesting further confirmation, allowing attacker-triggered workflows to execute automatically.

Manifold assigned a CVSS severity score of 7.7 under the default approval model and 9.6 when unattended execution is enabled.

The researchers say a straightforward mitigation would be to reject any click event that was not generated by a genuine user, preventing scripts from activating these workflows through synthetic browser events.


Researchers identify second permission-handling concern

Manifold also disclosed a separate issue involving how the extension initializes permission settings when its side panel loads.

According to the researchers, if the panel starts with a specific URL parameter indicating that permission checks should be skipped, the extension immediately enters a mode that bypasses user approval for supported actions.

Although users receive a warning indicating that Claude now has broader authority to perform actions on their behalf, the privileged session has already been established by the time the notification appears.

The researchers emphasize that this second issue is not directly exploitable under current conditions because the parameter can presently be generated only by the extension itself. Nevertheless, they argue that any future vulnerability allowing a lower-privileged component to influence this parameter could eliminate the remaining approval barrier and enable silent execution.

Potential attack paths discussed by the researchers include future message-handling flaws, panel initialization bugs or cross-site scripting vulnerabilities that could expose the parameter to untrusted input.

To reduce that risk, Manifold recommends that the extension ignore permission-related values supplied through URLs and instead always initialize new sessions in approval mode.

The researchers classify the forged-task technique as an example of indirect prompt injection within the OWASP Top 10 for Large Language Model Applications because an attacker manipulates the AI agent into executing one of its own predefined workflows rather than supplying new instructions directly.

They also associate the unattended execution scenario with excessive agency, referring to AI systems that are granted broad authority to perform sensitive actions with minimal user oversight.

According to the report, these behaviors occur regardless of whether users are running Claude Opus, Sonnet or Fable, indicating that the weaknesses originate in the browser extension rather than the underlying language models.


Issues remain unresolved months after disclosure

Manifold Security reported both vulnerabilities to Anthropic on May 21 while testing version 1.0.72 of the extension. Anthropic acknowledged the reports the following day.

The forged-click issue was closed on the basis that it fell within the scope of the previously reported ClaudeBleed investigation, which Anthropic indicated remained open while a more comprehensive solution was being developed.

The permission-handling report was classified as informational because the relevant parameter was intended for workflows that users had already configured for unattended execution.

Despite those responses, Manifold says it found the same vulnerable code paths unchanged after examining version 1.0.80 released on July 7.

As of July 14, the researchers noted that no CVE identifier had been assigned to either issue and Anthropic had not published a public advisory addressing the findings.

The latest research follows a series of security concerns involving AI-powered browser agents.

Earlier this year, researchers disclosed ClaudeBleed, a vulnerability that allowed websites to inject prompts into Claude for Chrome by exploiting how the extension trusted requests originating from the Claude website itself rather than verifying which script generated them.

LayerX, which originally disclosed ClaudeBleed, described the issue as a classic "confused deputy" problem, where software possessing legitimate privileges unknowingly performs actions on behalf of an untrusted requester.

Security researchers have also identified comparable trust-boundary weaknesses affecting other Anthropic products, including Claude Code, demonstrating broader challenges associated with AI agents that can directly interact with browsers, developer environments and online accounts.

The latest findings reinforce the importance of carefully validating user intent before granting AI assistants access to sensitive online services. As AI-powered browser agents become increasingly capable of interacting with email, documents and productivity platforms, researchers argue that ensuring those actions genuinely originate from users remains one of the most critical security controls.

Read more »
Technology
Browser Google Microsoft ModHeader Technology

Microsoft and Google Remove ModHeader After Finding Dormant Collector


ModHeader is a famous header-editing extension with over 1.6 million installs across Microsoft’s Edge and Google’ Chrome browser. 

Google and Microsoft remove the collector

Experts discovered a secret browsing-history collector built into its official store variant, and have withdrawn the ModHeader from Google and Microsoft.

An empty allow-list kept the collector switched off and it was dormant, and no proof has surfaced that it retrieved or sent even one browsing domain.

About the discovery

Stripe OLT, a UK cybersecurity organization analyzed the code against Google’s Web Store signature and verified the collector shipped within the authentic extension, not a fake one.

Stripe OLT’s study covers the Chrome build and its 900,000 users (an estimate); and Edge and its 700,000 users. Microsoft removed  the listing on July 3rd whereas Google pulled the Chrome listing a week after, on July 10th.

Attack tactic

Variant 7.0.18 still edits HTTP headers as shown. The same minimized background also consists of another system. On the first attempt, it makes a device fingerprint and deploys a hardcoded encryption key. As the user browses, it takes the domain from each page that user opens, encodes it, and gathers it locally, up to 1000 different domains.

Scheduler and other things

A scheduler combines your fingerprint with the encrypted list, uploads it to api.stanfordstudies[.]com, and deletes the local copy once a day. If the collector were turned on, browsers using it wouldn't all beacon at once because the upload time is offset per install. The same pipeline is described in separate teardowns by researcher Yunus Aydin on version 7.0.17 and HackIndex on version 7.0.18.

How does collector function

The collector functions only if your browser matches an entry on an internal allow-list, but the list ships empty. Every time, the check fails, and the pipeline stops before it gathers even a single domain. 

The small change is populating the list, without any click and no new permissions from the users, sent as a routine update. The endpoint URL, the scheduler, the storage logic, and the hardcoded key are all on the same device.

But not everything was silent. The extension pinged extensions-hub[.]com with the product, version, and browser when it was installed, updated, and uninstalled. 

Additionally, it was evident that the piece had been running because a script that runs on every page had already recorded actual request metadata in plain text to local storage. 

Read more »
Technology
AI ai agents ChatGPT Claude Google Microsoft Technology

GhostApproval Symlink Codes Could Run Malicious Codes in AI Coding Agents


Cyber security experts at Wiz discovered that a bug in six famous AI coding assistants allows a booby-trapped code project to silently take over a developer’s system. The assistant can ask access to edit one innocent-looking file, but the write takes over a sensitive file.

The impacted tools are Windsurf, Google Antigravity, Cursor, Amazon Q Developer, Claude Code by Anthropic, and Augment. Wiz has termed the technique GhostApproval and posted it recently.

Three of the six AI assistants have addressed, two did not, while Anthropic argues if it is a bug. The most vulnerable are the tools that modify file before you can notice.

Attack tactic

The threat actors exploit an old Unix feature called symlink (or symbolic link), that AI assistants cannot check. 

A symlink silently directs to other files somewhere else on disk, hence writing to it particularly writes to the victim. 

“Symbolic links have been a security headache since the early days of Unix. From /tmp race conditions to privilege escalation exploits, symlinks have a long history of bypassing security boundaries by making one path silently resolve to another. It's a well-documented attack primitive - CWE-61 dates back decades,” Wiz said.

Research model

Wiz made a malicious repository with a symbolic link called project_settings.json that really directs to target’s SSH login file, ~/.ssh/authorized_keys. The repo’s README commands the assistant to put “a line” to project_settings.json, and this line is the hacker’s SSH key mimicking an innocent setting. “

If you ask the agent to “set up the workspace” or “follow the README,” it writes the key directly via the symlink into the login file. Following this, if the machine plays an SSH  service the threat actor can access, they can sign in without password. 

The second variant

Another variant of the attack writes to your shell startup file, ~/.zshrc, which the shell runs the next moment you open a terminal without needing an SSH. There are no indications that any of this has been abused in real-time operations, Wiz has only demonstrated it as their research.

“Symlinks have been exploited for decades – in race conditions (CVE-2018-15664), in package managers (CVE-2021-32803), in container escapes (CVE-2024-21626). Any time a tool writes to a user-controlled path without resolving it first, symlinks become a weapon,” Wiz wrote in its blog. 

Read more »
Google
AI Chatbots Cyber Attacks Dialogflow Google

Rogue Agent Bug Could Have Let Attackers Hack AI Conversations


A critical vulnerability in Google’s Dialogflow could have let a hacker exploit other Code-Block-enabled agents via one Code Block-power agent, in one Google Cloud project.

After this, the attacker could read chats, steal user data, and command bots to send hacker-written texts such as re-entering a password.

Discovery of the bug

Cyber security firm Varonis discovered the tactic and called it ‘Rogue Agent.’ The bug impacted only businesses that make agents with custom Code Blocks and Dialogflow’s Playbooks, which allows hackers to add their own Python. The attack was not remote, or unauthorized.

For the attack to happen, it required the dialogflow.playbooks.update green light one such agent, which restricts the hacker to an infected insider or a breached developer account, not some stranger on the web. From that point, the reach extended to every agent inside the project.

Google has patched the bug, and Varonis and Google have said there are no signs that the flaw was deployed in a real attack or campaign.

Single writable file prompted each agent Code Blocks

Dialogflow’s Code Blocks allows developers to add custom Python to a chatbot’s flow to test input, invoke defined tools, and control behavior. 

The code runs within a Google-operated Cloud Run environment, and every agent that uses Code Blocks in the similar Google Cloud project shares one incident of it. The customer cannot control or see the environment that Google runs, meanwhile Varonis discovered no real separation between the agents within it.

Attack tactic

When the agent runs a Code Block, the code is added to internal setup code and sent to Python’s exec()function. The functions and variables that block can touch are defined by the setup. 

Functions consist(), which makes the bot reply with a given string, whereas variables consist of a history of full chats and state for session information such as the session ID.

Varonis discovered code_execution_env.py, the file that does this wrapping, lying in the shared environment with write access. 

As the file was writable, a single Code Block could change it. The block downloads an altered code_execution_env.py from a threat actor-controlled server and overwrites the original within the running container.

After that, the attacker’s variant commands every Code Block deployment throughout every agent that shares the environment. The attacker’s code sits in the same place as the real code, with similar access to respond(), state, and history, 

Read more »
Threat Intelligence
Google Joint Operation NetNut Proxy Cyber Security Threat Intelligence

Google Cripples NetNut Proxy Network Spanning 2 Million Devices

 

Google has delivered a major blow to NetNut, one of the world’s largest residential proxy networks, by crippling its ability to route malicious traffic through millions of compromised home devices. The operation, conducted in coordination with the FBI, Lumen, and other partners, marks a significant escalation in the fight against infrastructure that cybercriminals rely on to hide their activities. 

Google’s Threat Intelligence Group (GTIG) estimates that NetNut—also tracked under the name Popa—spanned at least 2 million devices globally, including smart TVs, streaming boxes, and other internet-connected appliances. In a single week in June, Google observed 316 distinct threat clusters using suspected NetNut exit nodes to mask their location and carry out activities such as password guessing and malware distribution. By disabling accounts and services tied to NetNut’s command-and-control infrastructure, Google says it has reduced the network’s usable device pool by millions, severely degrading its business operations. 

NetNut grew by embedding its software development kit (SDK) into seemingly legitimate apps and firmware, often on low-cost or no-name hardware. Many victims unknowingly installed applications that promised payment for “unused bandwidth” or “sharing your internet,” a common lure for these networks. Once integrated, the SDK turned devices into relays for other people’s traffic, making malicious activity appear to originate from ordinary home IP addresses and helping attackers bypass security tools and geo-restrictions. 

Google’s response combined legal, technical, and user-protection measures. The company disabled infrastructure used for NetNut-related malware operations, shared detailed technical intelligence on the group’s SDK and backend systems with law enforcement, and worked with partners to seize domains controlling compromised devices. On the user side, Google Play Protect was updated to automatically warn users and disable apps found to integrate the NetNut SDK, while Google identified hundreds of Android apps and thousands of Windows files linked to the network’s infrastructure.

While Google describes the action as a “degradation” rather than a full takedown—NetNut also operates through reseller programs and white-label brands—the disruption raises the cost and complexity for attackers using residential proxies. For everyday users, the incident underscores the risk of installing obscure apps, especially those offering payouts for bandwidth, and of using cheap, unbranded streaming devices. Sticking to official app stores, reviewing app permissions, keeping Play Protect enabled, and buying hardware from reputable manufacturers remain the best defenses against ending up as an unwitting node in the next NetNut-style network.
Read more »
Vertex AI
AI ethics cloud storage Data Harvesting SDK Google Google OAuth Python technology Vertex AI

Security Bug in Google Vertex AI Could Allow Model Upload Hijacking

 




Google has addressed a security flaw in the Python SDK for Vertex AI after researchers demonstrated that attackers could potentially intercept machine learning model uploads and substitute them with malicious files.

The issue was identified by researchers from Palo Alto Networks' Unit 42 team, who disclosed the findings through Google's bug bounty program. According to the researchers, the vulnerability could be exploited without compromising a target organization's cloud environment, stealing credentials, or tricking users through phishing campaigns. Instead, the attack relied on weaknesses in how the SDK handled temporary storage locations during model uploads.

Researchers referred to the technique as "Pickle in the Middle." They reported no evidence that the flaw had been exploited outside of controlled testing environments. Google has since released security updates, and organizations using Vertex AI are advised to upgrade to version 1.148.0 or newer.


Predictable Storage Names Created an Opening

The vulnerability originated from the SDK's automatic staging process.

When developers uploaded a machine learning model without manually specifying a Cloud Storage bucket, the SDK generated a temporary bucket name based on information such as the Google Cloud project identifier and deployment region.

The problem was not that the bucket name could be predicted. The problem was that the SDK only checked whether the bucket existed. It did not verify whether that bucket belonged to the project performing the upload.

Because Cloud Storage bucket names are globally unique across Google Cloud, an attacker could create the expected bucket before the victim did. If that happened, model files uploaded by the victim could be redirected into infrastructure controlled by the attacker.

In practical terms, a developer could believe a model was being uploaded to their own cloud environment while the files were actually being delivered elsewhere.


Attackers Could Replace Models Before Deployment

After receiving the uploaded files, an attacker could modify or replace the model before Vertex AI retrieved it for deployment.

This becomes particularly important because many machine learning workflows rely on serialization formats such as Pickle and Joblib. These formats are commonly used to save trained models, but they also contain functionality capable of executing instructions when the file is loaded.

As a result, a manipulated model may do more than generate predictions. It can potentially run arbitrary code inside the environment responsible for serving the model.

Unit 42 researchers demonstrated that this behavior could be abused to execute attacker-controlled code inside Vertex AI's serving infrastructure.


Researchers Exploited a Narrow Timing Window

The attack required the malicious file replacement to occur very quickly.

During testing, researchers observed that Vertex AI typically retrieved uploaded files roughly 2.5 seconds after the upload process completed.

To exploit this short interval, they created an automated Cloud Function that monitored the attacker-controlled bucket and immediately replaced newly uploaded files. The replacement process took approximately 1.4 seconds, allowing the malicious model to be swapped before Vertex AI accessed it.

This timing-based attack demonstrated that the vulnerability was practical under the right conditions rather than being a purely theoretical risk.


Proof-of-Concept Reached Beyond a Single Model

After achieving code execution, researchers tested what level of access could be obtained from the serving environment.

Their proof-of-concept extracted an OAuth token from the container's metadata service and used it to interact with resources available within Google's managed infrastructure.

According to the report, the token provided visibility into additional machine learning assets, model artifacts, TensorFlow files, BigQuery metadata, access control information, system logs, Kubernetes cluster identifiers, and internal infrastructure references.

The findings suggested that a successful compromise could potentially expose information beyond the originally targeted model deployment.


Exploitation Required Specific Conditions

The vulnerability was not universally exploitable.

Researchers noted that two requirements had to be met before the attack could succeed.

First, the expected default staging bucket could not already exist in the chosen deployment region. Second, the developer needed to rely on the SDK's default bucket-generation behavior rather than specifying a storage bucket manually.

The researchers noted that newly created Vertex AI projects often satisfy the first condition because the default bucket may not yet have been created.


Google Introduced Multiple Fixes

Unit 42 reported the issue to Google on March 5, 2026.

Google's initial response introduced additional randomness into bucket names by appending a UUID value, making bucket prediction substantially more difficult.

The company later strengthened the mitigation by implementing ownership validation checks. These checks ensure that automatically selected buckets belong to the project initiating the upload, preventing bucket-squatting attacks from succeeding.

The ownership verification mechanism was included in Vertex AI SDK version 1.148.0.

At the time the researchers published their findings, neither Google's Vertex AI security advisories nor the research report listed a CVE identifier for the vulnerability.


Recommendations for Organizations

Security teams using Vertex AI should verify that all environments are running updated versions of the google-cloud-aiplatform package. This includes development notebooks, machine learning pipelines, automated build systems, testing environments, and production deployments.

Researchers also recommend explicitly defining a staging bucket owned by the organization instead of relying on SDK defaults. This reduces the risk of storage misconfigurations and provides greater visibility into where machine learning artifacts are stored during deployment.

The disclosure is the latest example of how weaknesses in supporting cloud infrastructure can affect AI systems. As organizations continue moving model development and deployment into managed cloud platforms, security reviews must extend beyond the model itself to include storage, deployment pipelines, permissions, and the services that support the AI lifecycle.

Read more »
US
Ads Chrome Digital Ads Google Location Privacy Tech US

Hackers Use Phone Location Data to Attack US Military Personnel

Hackers Use Phone Location Data to Attack US Military Personnel

Threat actors are targeting U.S. military personnel deployed in active war zones, exploiting commercially available location data. 

This shows how the global surveillance economy (digital targeted advertising) affects battlefield security. 

Location data exposing military location

The US Central Command (Centcom) confirmed this attack and said, "multiple threat reports concerning adversary exploitation of commercial location data to target or surveil U.S. personnel in theater."

Details about the incident

This alarming development was shared with Reuters by Senator Ron Wyden, but no particular detail about the incident was offered. 

But Centcom’s operation area consists of the Gulf, where the US forces are at war with the Iranian military. This is the first time that US forces have confirmed it is being targeted in an active war zone with the help of digital ads that are exposing location data. 

Officials’ statements

According to Pentagon and the US lawmakers, “"commercial location data can be used to identify where U.S. troops congregate and their pattern of life, which can be exploited by adversaries to target attacks such as missiles, drones, and roadside bombs, and for counterintelligence."

Lawmakers warned that "commercial location data can be used to identify where U.S. troops congregate and their pattern of life, which can be exploited by adversaries to target attacks such as missiles, drones, and roadside bombs, and for counterintelligence."

The risk of digital advertising targeting in wars

Senator Wyden has warned that it is time to “"start treating the adtech industry as a national security threat." 
The problem has again exposed the underlying privacy threats concerning location data, which is the foundation of digital advertising.

The Pentagon did not return messages seeking comment, and lawmakers' efforts to obtain more information from military officials about the targeting reports.

Attack tactic

The location data is retrieved by apps through smartphones or service providers. For instance, a third-party sometimes collects the data which is sold on the web for advertising purposes.

The privacy threats of selling personal location data is not new. In 2016, a US defense contract bought commercially available location data to trace special ops forces from their domestic bases to a private staging post in Syria, according to a Wall Street Journal (WSJ) report. 

Recently, reporters from two German news outlets and the Wired used billions of coordinates from a data broker to leak detailed locations of individuals near eleven US military sites in Germany. 

The US lawmakers wrote a letter to the Pentagon which argued that military officials should act faster to protect military personnel, as their location is sometimes exposed due to the complex location data trade market.

The US lawmakers have suggested to:
  1. Disable location sharing on field smartphones
  2. Shifting military staff away from Google Chrome in favour of privacy focused browsers.
  3. Turn off digital advertising on military devices.

The impact

Advertising groups such as the Association of National Advertisers and the Interactive Advertising Bureau have not responded to any questions or comments.

North Carolina Republican and former U.S. Army Special Forces officer, representative Pat Harrigan, co-signed the letter, saying that browsers such as Google Chrome “are built from the ground up to collect and share user data. every day they remain on government-issued devices is another day we are handing our adversaries a weapon against our own troops.”

Responding to the statement, Google said that its browser has “industry-leading security" and has "long advocated for stronger rules and safeguards against data brokers."
Read more »
SafeBreach
Android Data Breach Gemini Google notifications SafeBreach

Researchers Show How Android Notifications Could Be Used to Manipulate Google Gemini

 





Security researchers have disclosed a now-remediated flaw that could have allowed specially crafted notifications from common messaging and social networking applications to influence the behavior of Google Gemini on Android devices.

The research was conducted by SafeBreach researcher Or Yair, who found that Gemini's ability to access and process notifications could be abused to deliver hidden instructions through otherwise legitimate messages. According to the findings, the technique did not rely on malware or a rogue application being installed on a target device. Instead, any service capable of sending a notification, including WhatsApp, Slack, Signal, Instagram, Messenger, or SMS, could potentially be used to deliver malicious content.

The study builds on SafeBreach's earlier "Invitation Is All You Need" research, which demonstrated how malicious Google Calendar invitations could manipulate Gemini through indirect prompt injection. Following that disclosure, Google introduced new safeguards designed to prevent external content from influencing sensitive actions. Yair's latest work examined whether similar manipulation could still occur through a different source of user data.

At the center of the issue was Gemini's Utilities feature on Android. The functionality allows the assistant to read, manage, and respond to notifications from connected applications. Researchers found that under certain circumstances, notification text could be interpreted not only as information but also as instructions that influenced the assistant's responses and actions.

Because the feature is available on Android devices and not through Gemini's web version or iOS implementation, the attack scenario was limited to Android users who had granted Gemini access to notifications.

According to SafeBreach, the number of potential entry points was unusually large because notifications can originate from countless applications and online services. This meant attackers would not necessarily need direct access to a device. Delivering a crafted notification could be sufficient to introduce malicious instructions into Gemini's processing workflow.

One of the simpler demonstrations involved altering the information Gemini presented to users. Researchers showed that manipulated notifications could cause the assistant to relay fabricated messages while making them appear to originate from legitimate contacts. In some scenarios, Gemini could process real notifications first and then attribute attacker-controlled content to an actual sender already present in the notification queue.

The researchers noted that this type of deception could be particularly effective when users interact with Gemini through voice. For example, someone driving a vehicle may hear a message that appears to come from a manager, colleague, or trusted contact and have little opportunity to verify the information displayed on the screen.

The research also examined Google's post-Calendar security protections. According to Yair, Gemini included mechanisms intended to prevent sensitive actions from being triggered without proper authorization. These checks evaluated both the user's response and the assistant's preceding output to determine whether a requested action was consistent with the conversation.

During testing, direct attempts to inject hidden commands were repeatedly blocked. To overcome these restrictions, Yair developed a technique called "Fake Context Alignment," which sought to make a user's approval appear valid to Gemini's authorization system while obscuring the true request from the user.

One variation involved displaying a sensitive authorization prompt in a language unfamiliar to the victim. Researchers used an example where a request such as "Do you want to open the window?" appeared in Chinese while a harmless English-language question followed. If the user responded with "Yes," Gemini could potentially associate that response with the hidden authorization request rather than the visible conversation.

A second technique relied on differences between information displayed on-screen and information spoken aloud by Gemini's text-to-speech system. Researchers found that certain hidden content embedded within hyperlinks might not be read aloud. In a demonstration, the visible interface contained a sensitive authorization request while the spoken response presented a routine message, increasing the likelihood that a user would unknowingly approve an action.

SafeBreach reported that combining these techniques increased the chances of bypassing the authorization safeguards that Google had introduced after the earlier Calendar-based attack research.

Once authorization was obtained, the researchers demonstrated several potential outcomes. Through integrations with Google Home, Gemini could interact with connected smart-home devices, including windows, lighting systems, and boilers. Additional demonstrations involved opening websites that could expose a user's approximate location through IP address information or trigger file downloads.

The research also explored interactions with third-party applications. In one proof-of-concept scenario, Gemini followed a trusted web address that later redirected to a Zoom link, resulting in the device joining an online meeting. SafeBreach emphasized that this occurred within a controlled testing environment and stated that its own public domain was not configured to redirect users to Zoom. Instead, the redirect was performed through a local test server used during the demonstration.

Researchers additionally identified a persistence mechanism involving Gemini's memory capabilities. Unlike the earlier Calendar-based research, the notification technique enabled the assistant to store attacker-controlled information as long-term memory. In one demonstration, Gemini was persuaded to remember an incorrect name for the user. Because memory is associated with a Google account rather than a single device, inaccurate information could potentially appear wherever that account later accessed Gemini.

The study also demonstrated the creation of recurring automated tasks. Researchers showed that instructions could potentially be scheduled to execute repeatedly, including examples involving regular access to recent messages at specific times.

SafeBreach disclosed the findings to Google's Vulnerability Reward Program on August 17, 2025. Google classified the report as a high-priority issue and later confirmed that changes to its content-classification systems mitigated both the notification-based prompt injection technique and the related authorization bypass method. The company confirmed the remediation on November 14, 2025.

No CVE identifier was assigned to the issue, and SafeBreach stated that it found no evidence indicating the technique had been exploited in real-world attacks before the fixes were implemented.

Because Google's mitigation was deployed through server-side updates, users did not need to install a software update to receive protection. However, individuals seeking additional safeguards can restrict Gemini's access to notifications by disabling the Utilities feature through Connected Apps settings or by revoking the Google app's notification-reading permissions on Android.

The findings provide another example of the security challenges that emerge as AI assistants gain access to messages, notifications, calendars, and connected services. As these systems become increasingly capable of performing actions on behalf of users, researchers continue to examine how external content can influence AI-driven decision-making and whether existing safeguards are sufficient to prevent misuse.

Read more »
workplace monitoring apps
bossware Data Privacy Data Sharing employee surveillance Google Technology worker privacy workplace monitoring apps

Study Reveals Workplace Monitoring Apps Share Employee Data With Major Tech and Advertising Firms

 

A recent study has raised concerns about the privacy practices of workplace monitoring software, revealing that many employee-tracking applications are sharing user information with major technology companies, advertising networks, and data brokers.

The research was conducted by experts from Columbia Law School, Northeastern University, Vanderbilt University, and the University of California, Berkeley. The team examined nine popular workplace monitoring platforms, commonly known as "bossware," including Hubstaff, Time Doctor, and Deputy. These tools are widely used by employers to monitor staff activities such as working hours, keyboard and mouse usage, screenshots, location tracking, application activity, and productivity levels.

According to the findings, all nine platforms transmitted employee-related information to external organizations. Researchers created both employee and manager accounts to study how data flowed through the applications and identified numerous instances where personal information was shared with third parties.

“The striking piece of this study is that every single platform, nine of nine bossware companies, shared worker data with outside companies,” Stephanie Nguyen told The Verge.

The investigation uncovered 121 cases where employee information, including names, email addresses, and company details, was sent to external entities such as Facebook, Google, Microsoft, and AppLovin. Researchers also found that sensitive information—including IP addresses, device specifications, and browsing activity—was shared with 145 third-party companies, among them Facebook, Google, LinkedIn, Bing, and Yandex.

The report warns that many workplace monitoring providers have adopted data collection practices similar to those seen across much of the consumer internet.

“Bossware platforms have adopted the same business model as much of the consumer internet: collect as much data as possible, retain it indefinitely, and repurpose it in ways workers neither expect nor meaningfully consent to,” the researchers warn.

Researchers further noted that companies may use collected information, such as app usage patterns and network connections, to draw conclusions about employee behavior, engagement levels, or even whether a worker may be considering a job change.

The study also highlighted location-tracking concerns. Approximately one-third of the platforms reviewed were capable of monitoring a worker’s precise location even when the application was running in the background and, in some cases, potentially outside working hours.

The researchers emphasized that workplaces should not evolve into environments of excessive surveillance and unchecked data collection.

“Banning the sharing and selling of workplace data now is critical to avoid locking in practices that undermine worker privacy, autonomy and economic security,” the report notes.

“Workers typically lack the ability to meaningfully refuse surveillance, to switch employers, or to stop using an employer-issued surveillance platform without risking their jobs and livelihoods.”

Several companies named in the study did not immediately respond to requests for comment. However, Deputy’s Chief Technology Officer, Ciaran Hale, stated that the company works only with trusted service providers necessary for platform operations, security, and reliability. He also argued that researchers may have confused marketing-related website cookies with the company's secure employee application. Researchers maintained that their review covered the entire user journey experienced by workers, from visiting the company website to using the application itself.

The findings have intensified discussions around employee privacy, workplace surveillance, and the growing role of data collection technologies in modern work environments.


Read more »
Verification
Data & Privacy Google Phone Storage Technology Verification

Google Tests 5GB Gmail Storage Limit for New Users Without Phone Verification

 


Google is experimenting with a new Gmail policy that limits some newly created accounts to 5GB of cloud storage unless users add a phone number to their account. Once a phone number is linked, the full 15GB of free storage becomes available.

The company confirmed the trial to Android Authority, explaining that the initiative is being tested in select regions to ensure a “high-quality storage experience.” Google also stated that phone number verification can improve account security and make account recovery easier. However, critics argue that tying the standard storage allocation to phone number submission raises privacy concerns.

There are several reasons why Google may be considering such a move. Adding a phone number can provide an additional method for recovering access to an account. That said, users already have alternative recovery options available, including backup email addresses and recovery contacts.

Google further claims that linking a phone number can help strengthen account protection. However, cybersecurity experts often regard methods such as passkeys, authentication apps, and Google prompts as more secure than SMS-based verification, which remains vulnerable to SIM-swapping attacks, phishing attempts, and other security threats.

Another possible motivation is reducing spam and fraudulent account creation. Spammers and scammers frequently create multiple accounts, and requiring phone verification could make this process more difficult. Still, some regions already mandate phone verification during account registration, while cybercriminals can often access temporary or burner numbers through VoIP services. Additionally, the 5GB restriction may not significantly impact bad actors who only use accounts for short-term activities.

Since Google has described the initiative as a test, it may never become a permanent feature. Nevertheless, some observers question the approach, arguing that restricting two-thirds of the standard free storage allocation until users provide personal information is problematic. A more transparent option, they suggest, would be requiring phone verification during account creation rather than limiting storage afterward.

The reduced storage limit could also affect other Google services. Because Google Drive storage is shared across products, users relying on cloud backups—such as WhatsApp backups—could encounter limitations much sooner under the 5GB cap.

Google has previously incentivized users to enhance account security by rewarding them with additional storage. In earlier years, the company offered an extra 2GB of cloud storage to users who completed a security checkup. By contrast, the current test restricts access to storage users would typically receive for free.

The trial also places Gmail closer to Apple’s free iCloud Mail tier, which offers 5GB of storage. However, competitors such as Microsoft Outlook and Yahoo Mail continue to provide 15GB ori more of free storage in many regions.

Some critics view the test as another example of technology companies gradually reducing the benefits of free services while requesting either payment or additional personal information. Similar concerns emerged when Google Photos ended its unlimited free photo backup policy and shifted users to a shared 15GB storage limit in 2021. Others point to the company's efforts to promote YouTube Premium by making the free viewing experience less attractive.

One positive aspect is that the reported storage restriction currently appears to affect only new accounts. Existing Gmail users who already have less than 5GB of stored data do not seem to be impacted. However, individuals looking to create secondary email accounts may still find the policy inconvenient, despite Google allowing multiple accounts to be linked to a single phone number.

The timing of the test has also fueled privacy debates, particularly among users concerned about sharing additional personal information with major technology companies. As discussions around data privacy and government access to information continue, some users may be hesitant to provide more identifying details than necessary.

For now, the phone number-linked storage limit remains an experimental feature. While Google cites security, account recovery, and spam prevention as key reasons behind the test, questions remain about whether restricting storage is the right way to encourage users to verify their accounts.
Read more »
unauthorised access
browser data Credential Theft Cybersecurity Google Infostealer malware Sensitive data Storm unauthorised access

New Malware “Storm” Steals Browser Data and Hijacks Sessions Without Passwords

 



A newly identified infostealer called Storm has emerged on underground cybercrime forums in early 2026, signalling a change in how attackers steal and use credentials. Priced at under $1,000 per month, the malware collects browser-stored data such as login credentials, session cookies, and cryptocurrency wallet information, then covertly transfers the data to attacker-controlled servers where it is decrypted outside the victim’s system.

This change becomes clearer when compared to earlier techniques. Traditionally, infostealers decrypted browser credentials directly on infected machines by loading SQLite libraries and accessing local credential databases. Because of this, endpoint security tools learned to treat such database access as one of the strongest indicators of malicious activity.

The approach began to break down after Google Chrome introduced App-Bound Encryption in version 127 in July 2024. This mechanism tied encryption keys to the browser environment itself, making local decryption exponentially more difficult. Initial bypass attempts relied on injecting into browser processes or exploiting debugging protocols, but these techniques still generated detectable traces.

Storm avoids this entirely by skipping local decryption. Instead, it extracts encrypted browser files and quietly sends them to attacker infrastructure, removing the behavioural signals that endpoint tools typically rely on. It extends this model by supporting both Chromium-based browsers and Gecko-based browsers such as Firefox, Waterfox, and Pale Moon, whereas tools like StealC V2 still handle Firefox data locally.

The data collected includes saved passwords, session cookies, autofill entries, Google account tokens, payment card details, and browsing history. This combination gives attackers everything required to rebuild authenticated sessions remotely. In practice, a single compromised employee browser can provide direct access to SaaS platforms, internal systems, and cloud environments without triggering any password-based alerts.

Storm also automates session hijacking. Once decrypted, credentials and cookies appear in the attacker’s control panel. By supplying a valid Google refresh token along with a geographically matched SOCKS5 proxy, the platform can silently recreate the victim’s active session.

This technique aligns with earlier research by Varonis Threat Labs. Its Cookie-Bite study showed that stolen Azure Entra ID session cookies can bypass multi-factor authentication, granting persistent access to Microsoft 365. Similarly, its SessionShark analysis demonstrated how phishing kits intercept session tokens in real time to defeat MFA protections. Storm packages these methods into a commercial subscription service.

Beyond credentials, the malware collects files from user directories, extracts session data from applications like Telegram, Signal, and Discord, and targets cryptocurrency wallets through browser extensions and desktop applications. It also gathers system information and captures screenshots across multiple monitors. Most operations run in memory, reducing the likelihood of detection.

Its infrastructure design adds resilience. Operators connect their own virtual private servers to Storm’s central system, routing stolen data through infrastructure they control. This setup limits the impact of takedowns, as enforcement actions are more likely to affect individual operator nodes rather than the core service.

Storm supports multi-user operations, allowing teams to divide responsibilities such as log access, malware build generation, and session restoration. It also automatically categorises stolen credentials by service, with visible rules for platforms including Google, Facebook, Twitter/X, and cPanel, helping attackers prioritise targets.

At the time of analysis, the control panel displayed 1,715 log entries linked to locations including India, the United States, Brazil, Indonesia, Ecuador, and Vietnam. While it is unclear whether all entries represent real victims or test data, variations in IP addresses, internet service providers, and data volumes suggest ongoing campaigns.

The logs include credentials associated with platforms such as Google, Facebook, Twitter/X, Coinbase, Binance, Blockchain.com, and Crypto.com. Such information often feeds into underground credential marketplaces, enabling account takeovers, fraud, and more targeted intrusions.

Storm is offered through a tiered pricing model: $300 for a seven-day trial, $900 per month for standard access, and $1,800 per month for a team licence supporting up to 100 operators and 200 builds. Use of an additional crypter is required. Notably, once deployed, malware builds continue operating even after a subscription expires, allowing ongoing data collection.

Security researchers view Storm as part of a broader evolution in credential theft. By shifting decryption to remote servers, attackers avoid detection mechanisms designed to identify on-device activity. At the same time, session cookie theft is increasingly replacing password theft as the primary objective.

The data collected by such tools often marks the beginning of further attacks, including logins from unusual locations, lateral movement within networks, and unauthorised access patterns.


Indicators of compromise include:

Alias: StormStealer

Forum ID: 221756

Registration date: December 12, 2025

Current version: v0.0.2.0 (Gunnar)

Build details: Developed in C++ (MSVC/msbuild), approximately 460 KB in size, targeting Windows systems


This advent of Storm underlines how cybercriminal tools are becoming more advanced, automated, and difficult to detect, requiring organisations to strengthen monitoring of sessions, user behaviour, and access patterns rather than relying solely on traditional credential protection methods.


Read more »
Subscribe to: Posts (Atom)