CRXfiltrate / Sales FAQ

This is the most common pushback and it has three answers.

First, install count is not the right ceiling. The cluster delivers through two vectors: malicious extensions AND third-party tracker chains served on legitimate websites. Users who never installed any extension still get the payload through page-served delivery. Install count reflects consumer behavior. Enterprise exposure comes from the same browsers being used at work the next morning. Install count isn't the ceiling on enterprise exposure, it's the floor.

Second, "already removed" misses the operational reality. At the time we published, three confirmed cluster extensions were still installable (one on Chrome Web Store as an unlisted but live listing, two on Microsoft Edge Add-ons). Store takedowns don't retroactively uninstall the extension from endpoints where it's already running, and Chrome Web Store takedowns don't reach Edge at all. Removal of a listing is not remediation.

Third, the operation is actively expanding. Wladimir Palant first documented this cluster in January 2025. The operator has been expanding infrastructure through every wave of takedowns since. As of publication, we added seven new C2 and ad-delivery domains to the IOC blocklist three days before going public. Today the YARA fingerprint surfaces 23+ additional cluster extensions that were not in any prior reporting.

The honest answer is that across the customer environments where CRXfiltrate was live, several endpoint sensors did flag the DNS queries in raw telemetry. The detection pipelines above the sensors never promoted any of it to an alert a SOC analyst would actually see. The signal existed; the surfacing failed.

That is the gap proactive hunting against raw telemetry closes. We are not arguing your EDR is bad. We are arguing that the alert pipeline above your EDR is built to suppress noise, and the threshold above which CRXfiltrate-class signals get surfaced is higher than the threshold at which they actually exist in your telemetry.

If a customer pushes hard, offer them a focused hunt against the published IOCs in their environment as a tangible deliverable. We can run that.

The page-served delivery vector defeats DLP and SASE in the cases we observed. The C2 traffic uses domains that don't match adversary-themed denylists, and the payload is JavaScript executing inside a sanctioned-host browser context. From the network's perspective, it looks like a user reading a legitimate website.

The identity harvesting block exfiltrates the signed-in Google account's real name and email through what looks like normal third-party tracker traffic. SASE policies that allow general web browsing allow this exact pattern.

This is not a "your tooling is wrong" pitch. It's a "this specific class of threat exists outside the assumptions those tools were designed for" pitch.

This is the right question and the answer is in the architecture, not the current payload.

The shipped payload monetizes through ad fraud today. That's the visible part. What we documented is that the mechanism (declarativeNetRequest CSP strip, then direct DOM script injection from C2 response) supports any JavaScript the server chooses to deliver, on any page the user visits. Banking. SSO portals. Admin consoles. Internal apps. The architecture is operator-controlled code execution in the realm of every page, controlled at the C2.

What CRXfiltrate is doing now is not what CRXfiltrate is capable of. The architecture is the threat. The payload is what they're choosing to do with it this quarter.

One concrete data point: one captured payload variant contains an active function that exfiltrates the signed-in Google account's real name and email to a separate C2. We also observed a variant where that block was removed, so the operator is actively iterating on what to ship.

Manifest V3 was supposed to restrict what extensions could do, including limiting remote code execution. The cluster works around this in a specific way.

The extension uses the declarativeNetRequest API to strip Content Security Policy headers from the responses of pages the user visits. CSP is what tells the browser "only load scripts from these origins." With CSP stripped, the browser will execute any script the page contains.

Then, separately, the extension makes a network request to the C2 and uses the response (which contains JavaScript) to inject script tags directly into the page's DOM. Because CSP is no longer enforcing origin restrictions, this works. Operator-controlled JavaScript runs in the realm of the page, with the same permissions as the page's own scripts.

This is not technically "remote code execution by the extension," which is what Manifest V3 was designed to prevent. The extension itself doesn't execute remote code. It modifies headers and the DOM. The page executes the remote code, because the extension changed the conditions under which the page would execute it.

Vector A is malicious extensions. The user installs the extension (or it gets installed via a third-party bundler), and the extension delivers the payload.

Vector B is page-served. Legitimate websites include third-party trackers that are part of the same infrastructure cluster. When the user visits any site that loads one of those trackers, the tracker delivers a similar payload. The user does not need to have any extension installed.

Vector B is why a clean extension inventory does not rule out exposure. The published IOCs include both extension IDs (for Vector A) and DNS/domain indicators (for Vector B). Customers running a hunt should sweep both.

The operator runs a templated decoy generator. They take the same architectural template and word-swap minor strings in the manifest (adjustment to correction, enhance to enhancement) to produce new extension variants. Each variant has a different name, different developer account, different cosmetic identifiers, but the same underlying code structure.

Exact-string IOC matching only catches the variants you already know about. The structural YARA fingerprint catches the architectural pattern shared across all of them, including the ones that haven't been published yet. That's why we keep finding more cluster extensions when we run the fingerprint against fresh submissions.

We have not attributed publicly. The infrastructure analysis points to a single organized operator running a publishing operation, evidenced by the 12 compartmentalized developer accounts, the versioned release pipeline, the internal ticket references in the production payload, and the architectural consistency across every extension we obtained source for.

If a customer presses on attribution, redirect to the operational pattern: this matters less than the fact that the operator has been running continuously since at least January 2025, expanding through takedowns, and shipping new variants on cadence. The exposure is real regardless of who is behind it.

Two-part answer.

First, run the published IOC list against your DNS logs and endpoint extension inventories. The IOC packet at 7ai.com/crxfiltrate includes both. The YARA rules can be run against extension source you've already pulled. The Suricata rules can be deployed in inline mode against network traffic.

Second, and this is the more honest answer: you probably have endpoints with the right DNS telemetry to flag this already. The question is whether your detection pipeline ever surfaced it. If you've never seen a CRXfiltrate-related alert in your queue, that doesn't mean you weren't touched. It means your pipeline didn't promote the signal.

If you want a definitive answer for a specific environment, that's where a focused proactive hunt comes in. We can scope that engagement.

This is a good problem to have and a real opening. The point is that CRXfiltrate is one campaign. The pattern (active operator, templated variants, infrastructure expansion through takedowns) is widespread. The threat hunt service that surfaced CRXfiltrate is continuous, not one-off.

Specifically, the Threat Hunt and Threat Intel Hunt capabilities launching June 1 turn this into a recurring capability. Every new piece of intel that drops triggers a proactive sweep across customer environments. The next campaign that matters to a customer might not be reported publicly yet. That's the value proposition.

Don't take this bait. Nobody guarantees safety, and any vendor that does is overpromising.

Better framing: "With 7AI in place, CRXfiltrate-class campaigns become a finished investigation, not a missed alert. Your team gets a result that says either we found cluster activity in your environment and here's the scope, or we ran the hunt and didn't find indicators. Either way, you have an answer. Without proactive hunting, the most likely outcome is that the signal exists in your telemetry and never reaches the queue."

Yes. The research, the IOCs, the YARA, and the Suricata rules are all public. The full research is at 7ai.com/crxfiltrate, the blog version is at blog.7ai.com/crxfiltrate, and the one pager and threat brief PDFs linked from the campaign page are designed to be forwardable.

Public credit to Wladimir Palant for the January 2025 analysis that named the cluster. That's noted in the published research.

DXC Technology, BigID, Blackstone, Duck Creek Technologies, OneSpan, and Cole Scott & Kissane have all received the standard kit. If you are working a deal where one of those organizations is referenceable, you can mention that this research came from production environments at that scale. Do not name specific customer findings.

That's a meaningful signal. Juliana Testa (Senior AI Security Engineer & Threat Researcher) and Phil Royer (AI Security Engineer, Threat Research) are both available for technical follow-ups under Juliana Testa's lead. Coordinate through Nate. Do not commit the team to a date without checking.

A handful of phrases to avoid in CRXfiltrate conversations:

• "The 7AI platform detected this." This was a human-led hunt by Juliana through PLAID ELITE. Do not credit the platform alone.
• "Autonomous SOC." We don't use this term. Use "agentic security" or "AI agents that work for security teams."
• Any competitor name. Speak about categories ("traditional MDR," "legacy SOAR," "alert-driven detection") instead.
• "You're already infected, you just don't know it." That's FUD. The honest version is "the signal probably exists in your stack; the surfacing is what's missing."