root@markcardiff:~/reports$ ./render incident-report --public-safe --redacted

WordPress ClickFix-Style Web Compromise

Public-safe incident report on a redacted customer-facing WordPress support site, referred to as customer-support.example. The incident involved malicious JavaScript injected through plugin assets and a rogue plugin masquerading as a site-health component.

Published 2026-08-21 12:01 UTC

Focus incident report

Platform WordPress CMS

Customer redacted

Highpublic-site compromise

2delivery points found

ClickFixsocial-engineering lure

Redactedno customer domain disclosed

Executive summary

A customer-facing WordPress support site, referred to here as customer-support.example, was compromised and used to deliver ClickFix-style malware lures to visitors. The compromise involved malicious JavaScript injected through WordPress plugin assets and a rogue plugin masquerading as a legitimate site-health/performance component.

The attacker’s loader used obfuscation, blockchain-hosted configuration, and staged remote script loading to dynamically control what was shown to victims. The visible symptom was a browser popup or full-page overlay consistent with fake verification and ClickFix delivery chains.

The customer removed the malicious components and initiated hardening actions. This report intentionally avoids naming the affected organization or domain.

Conceptual chain observed during public-facing triage. The exact initial-access vector was not proven from passive review.

Key takeaways Scope and limitations Incident overview Technical findings Impact Likely attack path Remediation Detection opportunities MITRE ATT&CK Defensive lessons Public-safe indicators

Key takeaways

The incident affected a WordPress-based public support site.
Two malicious delivery mechanisms were identified: a rogue WordPress plugin and malicious JavaScript appended to an existing plugin asset.
The attacker used blockchain RPC endpoints to retrieve configuration or payload-location data, reducing reliance on a single static command-and-control URL.
The JavaScript behavior was consistent with ClickFix-style social engineering: fake browser/security prompts that attempt to convince users to run attacker-supplied commands.
The most likely root-cause classes are compromised admin/hosting credentials, vulnerable plugin/theme code, or another arbitrary file-write path. Passive external review alone could not prove the initial ingress vector.

Scope and limitations

This report is based on defensive external triage of the affected public site and passive WordPress component enumeration. It does not include private customer identifiers, the real affected domain, credentials, personal data, customer-specific telemetry, or exploit instructions.

The assessment focused on confirming malicious client-side code, identifying observable indicators, and supporting immediate remediation.

Incident overview

The affected site was a WordPress-powered public support portal. During triage, malicious JavaScript was observed in the public page source and linked frontend assets. The initial malicious component was a rogue plugin under a randomized-looking plugin directory. It presented itself as a WordPress performance or site-health troubleshooting plugin, but its behavior was unrelated to normal site diagnostics.

After that plugin folder was removed, the visible page source no longer contained the original loader. However, the popup behavior persisted. Further analysis identified a second malicious payload appended to an existing plugin JavaScript file. This second-stage payload used base64 encoding, XOR obfuscation, and dynamic JavaScript execution.

This demonstrates a common incident-response lesson: removing the first obvious malicious file is not enough. Attackers frequently establish more than one persistence or delivery point.

Technical findings

Finding 1: Rogue WordPress plugin loader

A suspicious plugin was found under a randomized-looking WordPress plugin path: /wp-content/plugins/site-helper-<redacted>/. The plugin metadata presented it as a benign site-health/performance plugin.

Avoided WordPress admin and login pages.
Loaded a bundled blockchain/Web3 JavaScript library.
Connected to public blockchain RPC endpoints.
Queried a smart contract for script or page content.
Conditionally targeted desktop operating systems.
Injected a full-screen iframe overlay using high z-index styling and Shadow DOM.
Used browser local storage to control display frequency.
Included logic to decode obfuscated payload blobs.

This is not normal plugin behavior for WordPress diagnostics. The behavior is consistent with malicious client-side payload orchestration.

Finding 2: Malicious code appended to an existing plugin asset

After the rogue plugin was removed, a second malicious payload was found appended to an existing plugin JavaScript asset: /wp-content/plugins/<existing-plugin>/public/assets/js/<plugin-bundle>.js.

atob() base64 decoding.
XOR transformation.
new Function(...) dynamic execution.
Public blockchain RPC endpoints.
A smart contract call to resolve the next-stage URL.
Remote loading of /api.php from the resolved host.

This second payload explained why users could still see a popup even after the first malicious plugin folder was deleted.

Finding 3: Blockchain-backed configuration

The malicious JavaScript used public blockchain RPC endpoints to retrieve attacker-controlled configuration. This provided infrastructure agility, resilience against simple URL blocking, payload rotation without modifying the compromised website again, and reduced visibility in static page-source review.

Defenders should treat blockchain RPC usage from ordinary public websites as suspicious unless explicitly expected by the application.

Finding 4: Public WordPress fingerprinting exposure

Passive review showed typical WordPress fingerprinting exposure, including plugin/theme version signals and public REST metadata. Some components appeared outdated at the time of review. This is not necessarily a vulnerability by itself, but it can assist attackers with target selection, vulnerability matching, and credential attacks.

Impact

The primary risk was visitor compromise through social engineering rather than direct compromise of the visitor browser through a browser exploit. ClickFix-style chains typically attempt to persuade the user to copy, paste, or execute attacker-provided commands under the guise of fixing a browser, CAPTCHA, Cloudflare, Teams, PDF, or security verification issue.

Malware execution on visitor endpoints.
Credential theft.
Session theft.
Installation of remote access tooling.
Reputational damage to the affected organization.
Search-engine or browser security blocklisting.
Further compromise if malicious code remains in cached assets or secondary plugin locations.

Likely attack path

The exact initial access vector was not proven from passive external review. The leading hypotheses are compromised WordPress administrator or hosting credentials, vulnerable or outdated WordPress plugin/theme code, abuse of a file manager/header-footer/code-snippet/plugin-editor capability after obtaining admin access, or supply-chain/unsafe plugin package installation from an untrusted source.

The strongest evidence is that attackers obtained write access to the WordPress filesystem or an equivalent administrative capability, because malicious code appeared in multiple plugin locations.

Remediation performed / recommended

Immediate containment

Remove the rogue plugin directory.
Identify and remove malicious code appended to existing plugin assets.
Delete and reinstall affected plugins from trusted vendor sources.
Purge WordPress, LiteSpeed, CDN, and browser caches.
Verify page source and fetched JavaScript assets no longer contain malicious indicators.

Follow-up remediation

Update WordPress core, all plugins, and all themes.
Rotate WordPress administrator, hosting panel, SFTP/FTP, SSH, and database credentials.
Invalidate active WordPress sessions.
Enforce MFA for administrative access.
Remove unknown administrator accounts.
Disable WordPress plugin/theme file editing.
Disable directory listing at the web server level.
Keep XML-RPC disabled unless explicitly required.
Restrict wp-admin access by VPN or trusted IP ranges where feasible.
Deploy file-integrity monitoring over WordPress core, plugins, themes, uploads, and configuration files.

Web and proxy detection

Public visitors loading modified plugin JavaScript files.
Requests for rogue plugin paths.
JavaScript assets containing atob, new Function, blockchain RPC hosts, or dynamically appended external scripts.
Browser requests to unexpected /api.php endpoints on unrelated domains.

Endpoint detection

For visitors or internal users who accessed the affected site during the exposure window, hunt for browser activity followed by suspicious process execution.

High-signal child processes: powershell.exe, pwsh.exe, cmd.exe, mshta.exe, wscript.exe, cscript.exe, rundll32.exe, regsvr32.exe.
Suspicious command-line content: -EncodedCommand, iex, iwr, irm, FromBase64String, mshta http, hidden PowerShell windows, or commands copied from the clipboard immediately after a browser prompt.

WordPress / hosting logs

Review the window around the first malicious file modification for successful wp-login.php authentication, plugin upload/install activity, plugin/theme editor access, file manager activity, unexpected POST requests to admin-ajax.php, SFTP/FTP logins, hosting control-panel file writes, and creation or modification of plugin directories and JavaScript assets.

MITRE ATT&CK mapping

T1190 — Exploit Public-Facing Application, if plugin/theme vulnerability was used.
T1078 — Valid Accounts, if admin or hosting credentials were abused.
T1059 — Command and Scripting Interpreter, for ClickFix chains that lead users to run commands.
T1204 — User Execution, for social-engineering-based execution.
T1027 — Obfuscated Files or Information, due to encoded/XOR-obfuscated JavaScript.
T1105 — Ingress Tool Transfer, if second-stage scripts or malware are downloaded.
T1566 / related social-engineering behavior, depending on delivery context.

Defensive lessons

Treat unexpected JavaScript changes in plugin assets as high severity.
Do not assume the first malicious artifact is the only persistence point.
Cache purging is a containment step, not remediation by itself.
Public WordPress plugin version exposure materially helps attackers target stale components.
Header/footer/code-snippet plugins are high-value persistence locations and should be tightly controlled.
Blockchain RPC usage from a conventional support site is a strong anomaly worth alerting on.

Public-safe indicators

The following indicators are suitable for defensive blocking or hunting. They are included without naming the affected customer site.

Rogue plugin naming pattern: site-helper-*.
JavaScript markers: wpCacheProbe, _5d4c6283eb, new Function(new TextDecoder().decode(...)).
Blockchain RPC infrastructure observed: mainnet.base.org, base.publicnode.com, base.drpc.org, 1rpc.io/base, polygon.drpc.org, rpc.ankr.com/polygon, 1rpc.io/matic, polygon-bor-rpc.publicnode.com.
Suspicious second-stage pattern: /api.php?s=<campaign-token>&_v=<time-window>.

Note: Some listed RPC endpoints are legitimate public blockchain infrastructure. They should not be treated as malicious globally. Their relevance here is anomalous use from an ordinary WordPress support site.

Conclusion

This incident reflects a common modern web-compromise pattern: attackers obtain write access to a CMS, inject malicious JavaScript into trusted public pages, and use the compromised site’s reputation to social-engineer visitors into executing malware. The use of blockchain-hosted configuration and multiple plugin-level injection points increased resilience and complicated initial cleanup.

The most important remediation steps are complete plugin replacement from trusted sources, credential rotation, administrative hardening, and file-integrity monitoring. The most important detection lesson is that runtime-loaded JavaScript and modified plugin assets deserve the same scrutiny as obvious injected script tags in page source.