Comet browser impersonation campaigns exploit launch-driven trust

At a glance

What this is: Bfore’s investigation shows that Perplexity’s Comet browser launch was quickly followed by fake domains, malicious ads and impersonation apps built to trap users searching for downloads.

Why it matters: This matters because browser launch hype creates a phishing and malware entry point that blends brand abuse, search poisoning and mobile impersonation into a single user trust problem.

By the numbers:

• 13 suspicious domains were investigated with varying threat levels.
• 8 domains were registered in 2025 following Comet’s launch timeline.

Context

Perplexity’s Comet browser created a familiar security pattern: a legitimate launch rapidly became a target for lookalike domains, fake apps and search-led deception. In practice, launch visibility becomes an attack surface when users rely on search results, ads or app stores instead of verified distribution channels.

The broader governance issue is not the browser itself but the trust chain around discovery and download. When brands generate urgent user demand, adversaries can exploit that demand with domain squatting, malvertising and app-store impersonation. enterprise browser security becomes relevant because browser trust now extends beyond configuration to distribution integrity.

Key questions

Q: What breaks when users search for a new browser download instead of using verified channels?

A: Search-first downloading breaks trust at the point where users are least able to verify authenticity. Attackers can place fake ads, parked domains and impersonation apps between the user and the real product, turning curiosity into malware delivery or credential capture. The failure is not technical alone, it is a governance gap in how organisations direct users to approved software sources.

Q: Why do launch campaigns create such a strong phishing and malware opportunity?

A: Launch campaigns concentrate attention, urgency and incomplete user knowledge into a short window. That combination lets attackers borrow brand recognition, register lookalike domains, imitate mobile apps and buy ads that appear to confirm legitimacy. The more public the launch, the easier it is for adversaries to exploit trust before users learn what the official download path looks like.

Q: How can security teams tell whether lookalike domains are becoming a problem?

A: The clearest signals are a spike in newly registered variants, parked pages, registrar churn, fake download keywords and search results that mimic official branding. If those patterns appear immediately after a product launch, the organisation should treat them as active abuse rather than isolated noise. Continuous monitoring matters because fraud campaigns often scale before users report them.

Q: What should organisations do when a product launch is already being impersonated?

A: They should combine takedown requests, DNS filtering, search and ad monitoring, and user communications that name the verified download path. The goal is to reduce exposure fast enough that users stop relying on search results or third-party pages. Account teams, help desks and security operations should share one response playbook so reports do not stall.

Technical breakdown

How launch timing drives domain squatting and search poisoning

Domain squatting works when attackers register lookalike names immediately after a product gains attention, then use parking pages, redirects or SEO tactics to catch search traffic. Search poisoning extends that logic by targeting common query phrases so malicious pages appear when users look for downloads. The security problem is less about one bad domain and more about a distributed discovery layer that users assume is trustworthy. Because the attacker does not need to break the product, only the user’s route to it, the control surface shifts to DNS, search, registrar monitoring and brand monitoring.

Practical implication: monitor newly registered lookalike domains and search-result abuse as part of launch-risk response.

Why fraudulent mobile apps remain effective around browser launches

Fake mobile apps exploit users who expect a companion app, a browser update or a branded helper utility. Attackers borrow the product name, copy visual cues and publish through app-store channels or ad funnels that look routine to non-specialists. In this case, the risk is amplified by the ambiguity of mobile categories, where a malicious app can hide in a lifestyle or utility listing while still impersonating a browser. For identity and access teams, the issue is not only malware on phones. It is also credential capture, session theft and user confusion about which app is authoritative.

Practical implication: treat app-store impersonation as a credential and session-hijack risk, not just a mobile malware issue.

How malvertising converts user intent into credential theft

Malvertising exploits the gap between what users search for and what they actually validate. Attackers buy or hijack ad placements, then point clicks to fake download pages that mimic official branding and workflow. Once the user believes the page is legitimate, the attacker can deliver malware, collect account data or push an executable disguised as the real product. This pattern matters because it collapses the distinction between advertising, distribution and authentication. The user treats the ad as a trust signal, but the attacker treats it as the first stage of the compromise chain.

Practical implication: block risky ad paths and force users through verified download and identity checks before installation.

Threat narrative

Attacker objective: The attacker wants to convert launch interest into fake downloads, harvested credentials or malware execution by abusing trust in the Comet brand.

1. Entry occurs when users search for Comet browser downloads and encounter spoofed domains, fake ads or impersonation apps instead of official channels.
2. Credential access or payload delivery follows when the user installs a fraudulent app or downloads an executable from a lookalike site that can capture data or deliver malware.
3. Impact is achieved through brand impersonation, credential theft, user deception and potential compromise of the browser session or surrounding accounts.

Breaches seen in the wild

• iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Launch-driven trust is now a security control failure, not a marketing side effect. The Comet case shows how quickly an AI browser launch can generate an ecosystem of fake downloads, parked domains and deceptive ads. Attackers do not need to compromise the vendor if they can intercept user intent at the point of search and download. Practitioners should treat product launches as governance events that require monitoring, takedown workflows and user validation paths.

Browser distribution has become part of the identity attack surface. Users do not just authenticate into browsers, they also authenticate trust in the path that delivers them. When that path includes app stores, ads and third-party download sites, the organisation inherits a trust chain it does not control. browser and computer-use agent security is relevant because browser-centric workflows now blur session use, identity context and download provenance.

Domain squatting against emerging products is a repeatable fraud pattern. The specific mechanics change, but the playbook is stable: register lookalike domains, host parking pages, place fake ads and wait for search traffic. That means defenders need early-warning monitoring tied to launch calendars, not just reactive takedown after the first complaint. The practitioner conclusion is simple: brand velocity without domain surveillance becomes a measurable exposure.

Mobile impersonation turns brand confusion into access risk. The fake app pattern is not merely consumer fraud. It can place a malicious endpoint between the user and the service, creating a route to credentials, tokens or sessions that support broader account abuse. Organisations with BYOD or unmanaged mobile estates need to assume that launch-themed impersonation is a realistic path into enterprise identities and user data.

Read next: Enterprise Browser and Browser Security Guide

What this signals

Launch-security drift: as AI browsers and other branded tools spread, the trust boundary moves from application code to the distribution ecosystem around it. That means domain registrations, ad inventory, app-store listings and search rankings now influence user risk as much as the software package itself.

Defenders should expect impersonation to follow the same pattern across future launches: lookalike domains first, fake apps next, then search and ad abuse that converts brand interest into user compromise. The operational response is to watch the ecosystem early, not only the endpoint after the download happens.

For practitioners

• Monitor launch-related lookalike domains Track newly registered domains that mirror product names, spelling variants and download keywords, then escalate parking pages, redirects and suspicious registrars for takedown review.
• Enforce verified download paths Direct users to official channels only, and make browser installation instructions explicit enough that search results and ads are not treated as trusted sources.
• Block fake app and ad pathways Use DNS filtering, ad controls and mobile app review workflows to reduce the chance that users land on impersonation pages or install lookalike apps.
• Brief employees on browser impersonation risk Explain that launch-day fraud often looks routine, especially when an AI browser, a helper app or a download page copies the real brand’s language and layout.
• Build a takedown workflow before launch Pre-plan registrar, search engine and app store escalation so impersonation reports can move quickly when a new product creates sudden user demand.

Key takeaways

• The core risk is that launch attention gives attackers a ready-made trust surface for domain squatting, fake apps and malvertising.
• Bfore identified 13 suspicious domains and 2 critical mobile app threats, showing that the abuse pattern was already active around the Comet launch.
• Verified distribution paths, domain monitoring and app-store response workflows are the controls that limit this kind of impersonation campaign.

Related NHI Mgmt Group resources: Browser and Computer-Use Agent Security Guide · Enterprise Browser and Browser Security Guide · Mobile Device Security Guide · Threat Modelling AI Agents

Key terms

• Package Squatting: The practice of publishing malicious packages whose names imitate legitimate brands, libraries, or namespaces. It succeeds when developers or automation choose based on familiar naming patterns and do not verify publisher identity or provenance before installation.
• Malvertising: The use of online ads to distribute malicious links or payloads. In this context it places cloned developer tool pages ahead of legitimate results, giving the attacker a trusted-looking entry point without needing an email campaign or direct social contact.
• App Store Impersonation: App store impersonation is the abuse of a trusted brand, name, or icon to make users install a malicious application. The technique relies on perceived authenticity rather than code exploitation, which is why monitoring publication channels matters as much as scanning source code.
• Launch-Driven Trust: Launch-driven trust is the temporary confidence users place in a new product because it is publicly visible, widely discussed or seemingly validated by search results and ads. Attackers exploit that confidence by inserting lookalike assets into the discovery path, turning product interest into a compromise opportunity.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect identity controls to the broader security decisions that shape real-world access risk.