When Search Becomes the Payload: Defending Against SEO / GEO / AEO Poisoning in the Real World

Search used to be the prelude to risk. Now, in many incident timelines, it o the risk.

A modern “download” journey often begins with a query, not with a vendor portal. If the top result looks right, most users treat that position as an implicit endorsement. Attackers have noticed. They don’t need a zero-day if they can win trust—and in 2026, trust is algorithmic: ranking systems, answer engines, and AI-powered retrieval.

This article is built around a fact-checked case study from Fortinet’s FortiGuard Labs: an SEO poisoning campaign that targeted Chinese-speaking Windows users by pushing spoofed software sites up the search results, then delivering malware via a staged redirect chain involving a script called nice.js. (Fortinet)

From there, we generalize into a defender’s model that covers three overlapping battlefields:

• SEO poisoning: manipulating traditional search ranking to drive human clicks.
• GEO poisoning: manipulating “generative engine” outputs by seeding the web or corpora with content optimized to be summarized by LLMs.
• AEO poisoning: manipulating answer-first systems (featured snippets, “answers,” agent tools) so the answer becomes the lure or the instruction.

We will stay strict about what is verified, and we’ll separate primary evidence (vendor research, standards bodies) from secondary reporting (news write-ups). Where something is plausible but not proven in the primary reports, it will be framed as a pattern—not as a claim about the specific campaign.

1) The New Trust Trap: Why “Top Result” Is an Initial-Access Channel

Defenders tend to model initial access as a small set of entry points: email, exposed services, removable media, supply chain. Search results are often treated as “user behavior,” a training problem.

That framing is outdated. Search is now a scalable, measurable initial-access surface because:

• The user intent is high (“I need this tool now”).
• The action is privileged (downloading and executing).
• The security prompts feel normal (installers request permissions).
• The attacker ROI is excellent (one well-ranked lure can outperform massive phishing volumes).

In the FortiGuard case, the operators abused SEO plugins and registered lookalike domains to place spoofed software sites prominently in search results, specifically targeting Chinese-speaking users. (Fortinet)

The insight to keep: they didn’t bypass security controls first; they bypassed the victim’s decision-making process.

2) A Verified Case Study: FortiGuard’s SEO Poisoning Campaign

What is confirmed (primary source)

According to Fortinet’s published analysis, in August 2025 FortiGuard Labs identified an SEO poisoning campaign aimed at Chinese-speaking users. The attackers:

• Manipulated rankings with SEO plugins.
• Used lookalike domains with small character substitutions.
• Hosted spoofed pages imitating legitimate software download sites.
• Used a staged chain involving a script named nice.js to redirect victims toward a final payload. (Fortinet)

Fortinet reports that the campaign delivered Hiddengh0st ve Winos variants. (Fortinet)

What secondary reporting adds (useful, but not primary)

Some secondary reporting and summaries expand on infrastructure themes and associated families (e.g., mentions of additional malware like kkRAT). Treat these as contextual, not authoritative over the primary report. (The Hacker News)

3) The Real Technical “Tell”: Redirect Ladders and nice.js

If you only focus on the final installer, you inherit an attacker advantage: they can rotate binaries faster than defenders can create signatures.

The more durable detection target is the delivery logic.

Fortinet describes nice.js as coordinating a multi-step redirect flow where the script returns JSON containing another URL, which returns another JSON response, ultimately leading to the final payload download. (Fortinet)

That matters because it creates a network-telemetry signature that often persists even as payloads change:

• Repeated HTTP(S) requests that return JSON objects containing URLs.
• Rapid, multi-hop navigations before the final binary request.
• Download events originating from recently seen domains that mimic brands.

Defensive takeaway: instrument and alert on staged redirect behavior, not just the final file hash.

4) “Trojanized Installer” Operations: Why They Keep Working

An installer is the perfect social-engineering wrapper:

• Users expect it to be executable.
• Users expect it to request elevation.
• Users expect network activity (“checking updates”).
• Users tolerate UI popups and downloads during install.

This is why “fake software site → installer” is such an effective initial-access pipeline, and why SEO poisoning isn’t “just marketing abuse.” It’s a delivery system.

To avoid overclaiming: the Fortinet report confirms the staged delivery and malware families; it does not necessarily publish every endpoint behavior detail that some write-ups attribute (e.g., exact persistence techniques). So in this section we talk about common patterns attackers use in trojanized installer chains, without asserting they all happened in the Fortinet case.

Typical patterns defenders should assume are on the table:

• A legitimate-looking installer wrapper plus a hidden payload dropper.
• Living-off-the-land binaries for execution and persistence.
• Anti-analysis checks that slow down or change behavior in sandboxes.
• Credential and session theft as the “profit phase.”

5) From SEO Poisoning to GEO / AEO Poisoning: When Answers Become the Attack Surface

Search poisoning used to be about ranking. The next wave is about being selected by models.

Once organizations plug LLMs into workflows—support bots, internal search, copilots, agentic automation—the threat model shifts:

• The user may no longer click a link.
• The model retrieves content, summarizes it, and acts on it.
• The “poison” can be embedded in text that looks like documentation.

This is why GEO/AEO poisoning is not just theory; it aligns with recognized LLM risk categories.

OWASP’s Top 10 for LLM Applications lists Hızlı Enjeksiyon as the top risk, and also includes Eğitim Verisi Zehirlenmesi ve Supply Chain Vulnerabilities as major categories. (OWASP Vakfı)

NIST highlights indirect prompt injection as attacks where adversaries inject prompts into data likely to be retrieved by LLM-integrated apps—exactly the structure you’d expect in GEO/AEO poisoning campaigns. (NIST Yayınları)

And UK National Cyber Security Centre warns that prompt injection is not analogous to SQL injection; the lack of a clean “data vs instruction” boundary makes it fundamentally harder to eliminate. (NCSC)

So the map looks like this:

• SEO poisoning: get a human to execute a payload.
• GEO poisoning: get a model to prefer your content in summaries.
• AEO poisoning: get a model to output an “answer” that becomes the user’s decision—or becomes an agent’s next action.

The shared failure mode: trust is delegated to systems optimized for relevance, not for adversarial integrity.

6) A Defender’s Threat Model for Poisoning Campaigns

Treat poisoning campaigns as a pipeline with three layers. This keeps teams from fixating on the “coolest” part (malware) and missing the “most repeatable” part (delivery).

Layer A: Attraction (how victims arrive)

• Ranking manipulation (SEO abuse)
• Lookalike domains
• Language targeting and localized lure pages
• High-intent queries (“download X”, “install X”, “crack”, “offline installer”)

Layer B: Delivery (how payload reaches the endpoint)

• Multi-hop redirect ladders (scripts returning JSON URLs)
• Disposable hosting and fast-rotating paths
• “Installer-shaped” payload packaging

Layer C: Execution and persistence (what happens after the click)

• Payload runs as part of install flow
• Persistence mechanisms
• Data theft, lateral movement, C2

Fortinet’s report provides high-confidence evidence for Layer A and Layer B in this campaign (SEO plugin abuse, lookalike domains, and nice.js staging), and confirms delivered malware families. (Fortinet)

7) The Practical Detection Game: Catch It Before the Binary Lands

7.1 Web proxy and network telemetry: detect the ladder, not the payload

Signals worth alerting on:

• Multiple redirects in short time windows, especially across unrelated domains.
• JSON responses that contain URLs, followed immediately by outbound navigation to those URLs (a “JSON ladder” pattern).
• Download of executables shortly after visiting a newly-seen domain.

If you run secure web gateways, create a rule group for high-intent software queries plus executable download plus untrusted domain age.

7.2 DNS controls: lookalike domains are a predictable problem

For enterprise environments, DNS filtering is one of the highest ROI controls. Blocklists are fragile; what you want is a policy layer that reduces exposure:

• Newly registered domains (NRD) filtering.
• Brand lookalike detection (homoglyph and edit-distance).
• Blocking categories like “newly observed file hosting” where practical.

7.3 Endpoint controls: block the “installer anomaly” behavior

Even when you can’t stop the download, you can stop the execution path:

• Application allowlisting (Windows Defender Application Control / AppLocker-type policies).
• Blocking execution from user-writable directories for high-risk file types.
• Enforcing Mark-of-the-Web handling and SmartScreen protections where possible.

8) A “Prove It” Validation Workflow (Windows)

The easiest way to reduce false confidence is to build a repeatable verification workflow: prove where the file came from, who signed it, what it does, and what it touched.

8.1 Quick file validation (safe, practical)

# Check Authenticode signature
Get-AuthenticodeSignature .\\Installer.exe | Format-List

# Hash the file (compare to vendor-published hashes where available)
Get-FileHash .\\Installer.exe -Algorithm SHA256

# Check for Mark-of-the-Web / Zone.Identifier (if present)
Get-Item -Path .\\Installer.exe -Stream Zone.Identifier -ErrorAction SilentlyContinue

If the file is unsigned, signed by an unexpected publisher, or lacks provenance information when it should have it, escalate.

8.2 A minimal “download provenance” checklist

Ask (and log) these every time:

1. What query led to the download?
2. What domain served the page?
3. Was there a redirect chain?
4. What domain served the binary?
5. Was the binary signed? by whom?
6. What process spawned it? from where?
7. Did it initiate outbound connections immediately?

This turns “user story” into investigative data.

9) Why CVEs Still Matter Here (Even When Poisoning Isn’t a CVE)

SEO/GEO/AEO poisoning is often “abuse,” not “vulnerability.” But attackers frequently combine poisoning with CVEs to reduce friction and increase reliability.

Here are CVE patterns that defenders should treat as high leverage in poisoned-download ecosystems:

CVE-2024-21412 (SmartScreen bypass)

This is widely described as a Microsoft Defender SmartScreen security feature bypass, with reputable vendor analysis describing exploitation narratives and the need to patch. (www.trendmicro.com)

Why it matters in this context: if you can bypass file-origin trust checks, you can turn a “scary download” into a “normal click.”

CVE-2023-38831 (WinRAR arbitrary code execution via crafted ZIP)

National Vulnerability Database describes CVE-2023-38831 as a WinRAR issue enabling arbitrary code execution when a user attempts to view a benign file in a ZIP that contains a similarly named folder with executable content, noting in-the-wild exploitation in 2023. (NVD)

Why it matters: poisoned download campaigns love archive-based deception because it rides on user expectations (“it’s just a picture / document”).

CVE-2022-30190 (Follina / MSDT RCE)

Microsoft published guidance explaining that CVE-2022-30190 enables remote code execution when MSDT is invoked via a URL protocol handler from a calling application like Word, allowing attackers to run code with the privileges of the calling application. (Microsoft)

CISA also issued an alert on the same issue and mitigation guidance. (CISA)

Why it matters: poisoned “how-to” pages and “download helpers” often lead to document execution paths in real enterprises.

CVE-2025-8088 (WinRAR exploitation still happening after patch)

Google Threat Intelligence Group reported widespread active exploitation of CVE-2025-8088 in WinRAR, noting that it was discovered and patched in July 2025 but continues to be exploited across diverse operations. (Google Cloud)

Why it matters: poisoning thrives on n-day reality—patches exist, but environments are messy, and attackers plan accordingly.

10) Controls You Can Actually Enforce (Not Just “Be Careful”)

A realistic enterprise baseline

1) Software acquisition policy with a “trusted path”

Make it explicit: software must come from vendor domains, official stores, managed catalogs, or internal mirrors. “Downloaded from search results” is not an approved path.

2) DNS + SWG enforcement

Use NRD filtering and lookalike detection to reduce exposure to spoofed domains. This is especially effective against campaigns that rely on newly registered lures.

3) Application control

If you can’t restrict downloads, restrict execution. Target the obvious: user-writable paths, temp folders, and high-risk script types.

4) EDR behavior detection

You want detections for:

• installer spawning unexpected child processes
• immediate outbound beacons post-install
• suspicious persistence creation

5) Tabletop exercises that simulate poisoned-search scenarios

Many teams drill phishing; far fewer drill “download from search.” This gap is exactly where these campaigns live.

Secondary commentary around the Fortinet-identified campaign emphasizes that users trust top results and that SEO poisoning leverages that trust at scale. (Security Buzz)

Use that insight to justify budget for controls beyond training.

11) Defending GEO / AEO Systems (LLM Apps, Agents, Internal Search)

If your organization is rolling out copilots, AI assistants, or agent workflows, you need “answer integrity” controls. This is not optional if the assistant can touch sensitive data or tools.

11.1 Enforce provenance and source-of-truth tiers

Basic policy that helps immediately:

• Require citations for any answer that claims a fact.
• Restrict which domains are eligible sources for high-risk actions (downloads, scripts, configuration changes).
• Maintain “gold sources” for internal runbooks and vendor advisories.

This aligns with the broader OWASP risk framing: injection, poisoning, and supply chain issues are core LLM security risks. (OWASP Vakfı)

11.2 Treat retrieved content as untrusted input

NIST describes indirect prompt injection as adversaries injecting prompts into retrievable data sources to exploit LLM-integrated applications. (NIST Yayınları)

That means your RAG layer is part of your attack surface.

Practical guardrails:

• Strip or quarantine instruction-like patterns from retrieved text when the system is about to execute tools.
• Separate “information retrieval” from “action execution” with explicit human confirmation on high-impact actions.
• Log the retrieval context that influenced any action (so you can investigate later).

11.3 Accept residual risk and design blast-radius limits

UK National Cyber Security Centre argues that prompt injection differs from SQL injection and may not be “solved” with a single clean mitigation approach; the implication is that system design must assume imperfect defenses and limit impact. (NCSC)

So build containment into the agent:

• Least-privilege tool access
• Network egress restrictions for agent runtimes
• Sandboxed execution environments for “download and run” workflows
• Rate limits and anomaly detection for tool calls

12) A Compact Mapping Table (So Security Teams Can Operationalize)

Poisoning layer	What it manipulates	Typical victim	Primary defensive lever
SEO poisoning	ranking + clickthrough	human user	DNS/SWG + policy + app control
GEO poisoning	what gets summarized by an LLM	human + model	source allowlists + provenance + corpus hygiene
AEO poisoning	what gets presented as “the answer”	human + agent	citation enforcement + action gating + tool sandboxing

This is a useful way to explain budget needs: controls differ because the trust boundary differs.

If your team treats SEO/GEO/AEO poisoning as “just awareness,” the program will decay into posters and lunch-and-learns. The stronger approach is continuous validation: kanıtlamak your controls work under realistic user behavior.

Penligent.ai can fit naturally in that validation layer, not as a magic shield. For example, you can use an automation-driven pentest workflow to continuously verify that:

• DNS and secure web gateway policies actually block lookalike domains and NRDs,
• endpoint execution controls prevent unsigned installers from launching in user-writable paths,
• egress and alerting rules catch staged-download patterns early, before payload execution.

Penligent positions itself as an AI-powered penetration testing platform oriented around reproducibility and evidence-chain reporting, which is exactly what security engineering teams need when turning “policy” into “provable control.” (Penligent)

If you want examples of how this style of “prove it” security writing can look in practice, Penligent’s long-form research posts (e.g., deep dives into specific CVEs and verification workflows) are a good reference format for engineering-first audiences. (Penligent)

13) A Defensive Appendix: What to Monitor and What to Block

13.1 Minimal signals to collect (if you collect nothing else)

• DNS queries + response IPs + domain age enrichment
• Proxy logs with redirect chains and content types
• Endpoint process creation (parent/child, command lines)
• File write events for executable and script types
• Outbound connections triggered by installer processes

13.2 A simple “risky download” policy statement you can enforce

If the organization cannot enforce “download only from approved sources,” it should enforce “execute only from approved publishers,” plus “no execution from user-writable locations,” plus “SmartScreen/MOTW integrity.”

That combination breaks many poisoned-search chains even when users still click.

Referanslar

• Fortinet / FortiGuard Labs analysis of the SEO poisoning campaign (includes nice.js staging and malware family notes). (Fortinet)
• OWASP Top 10 for Large Language Model Applications (Prompt Injection, Training Data Poisoning, Supply Chain). (OWASP Vakfı)
• NIST GenAI profile discussion of indirect prompt injection (retrieved content as attack vector). (NIST Yayınları)
• UK National Cyber Security Centre on why prompt injection differs from SQL injection. (NCSC)
• CVE-2023-38831 (WinRAR) — National Vulnerability Database entry. (NVD)
• CVE-2022-30190 (Follina) — Microsoft guidance + CISA alert. (Microsoft)
• CVE-2024-21412 (SmartScreen bypass) — reputable vendor and analysis coverage. (www.trendmicro.com)
• CVE-2025-8088 (WinRAR exploitation post-patch) — Google Threat Intelligence Group report. (Google Cloud)
• Penligent long-form CVE deep dive: Next.js Server Actions analysis (example of “prove it” narrative). (Penligent)
• Penligent long-form CVE verification-focused post: CVE-2025-49132. (Penligent)
• Penligent Hacking Labs index (for related posts). (Penligent)