woocommerce_inputs Plugin with Redirect and Concealment Hooks

Summary

This research entry documents a plugin directory named woocommerce_inputs and supplied PHP samples for Woocommerce custom inputs. The main sample registers an early redirect callback, visitor-address collection, recurring-event logic, plugin-list filtering, and removal of its deactivate link. A companion sample implements outbound HTTP retrieval.

Those structures justify focused review of the artifact. The retained screenshot shows only the directory, while both code samples are truncated before the complete behavior. This page therefore documents the hooks and network-fetch structure without claiming that a redirect succeeded or naming an unverified destination.

Investigation context

The directory was observed among ordinary plugins during one anonymized investigation. Its name differs from the legitimate woocommerce directory also visible in the file manager. Similar naming is useful for triage but is not proof by itself.

The broad fake and malicious plugin guide covers general plugin verification. This entry provides the narrower code-level fingerprint for woocommerce_inputs.

Observed artifact

The screenshot confirms the folder wp-content/plugins/woocommerce_inputs/. The red block in the breadcrumb is an irreversible redaction already present in the public derivative. Neighboring directories are context only and are not classified by this evidence.

Confirmed findings

• A woocommerce_inputs directory existed under wp-content/plugins.
• The supplied woocommerce_inputs.php sample identifies itself as Woocommerce custom inputs and uses the namespace WCInputs.
• Its constructor registers custom_redirect_function on template_redirect with priority 1.
• It registers collect_ip_address on both wp_head and admin_init.
• It registers custom scheduling, update-check, plugin-list, and action-link callbacks.
• Its GetIP method examines forwarded-address headers and REMOTE_ADDR, then validates public addresses.
• The supplied woocommerce-load.php sample constructs an HTTPS target and retrieves it with cURL or file_get_contents().

Technical analysis of the woocommerce_inputs plugin

Redirect and visitor-address hooks

template_redirect runs before WordPress renders the selected template. Registering at priority 1 gives the callback an early opportunity to alter response flow. The address collector is also attached to both frontend head rendering and administrator initialization.

The method bodies that decide when or where to redirect are not complete in the retained sample. Their names and registrations are confirmed; search-engine cloaking, successful redirection, address transmission, and destination selection are not.

Scheduling and concealment hooks

The constructor registers a custom cron schedule, an event hook, an all_plugins filter, and a filter for the current plugin’s action links. This is a distinctive combination because it joins recurring behavior with two administrator-interface controls.

The public excerpt does not reproduce identifiers, tokens, target construction, or the missing method implementations.

Redacted defensive excerpt

on plugin construction:
    register early template redirect handler
    register visitor-address collection in frontend and administrator contexts
    register recurring schedule and update callbacks
    register plugin-inventory filter
    register filter for this plugin's deactivate link

companion fetcher:
    build an HTTPS target from omitted data
    retrieve a response through one of two PHP HTTP methods

Analyst assessment

The combined callbacks are consistent with a fake plugin designed to make conditional response changes while reducing its visibility in ordinary plugin administration. The companion fetcher could supply data used by another method, but the truncated evidence does not establish that relationship at runtime.

The earlier draft described a complete search-referrer redirect chain. That level of detail is not supported by the retained portion of the samples, so it has been removed. A redirect should be treated as confirmed only when the complete method, logs, or observed response establishes it.

Indicators of compromise

Higher-confidence indicators

• Directory wp-content/plugins/woocommerce_inputs/
• Plugin identity Woocommerce custom inputs
• Files woocommerce_inputs.php and woocommerce-load.php
• Namespace and class combination WCInputs\\WC_Plugin
• The constructor-level combination of template_redirect, collect_ip_address, _cron_hook, all_plugins, and current-plugin action-link filtering

Contextual indicators

• template_redirect
• wp_head
• admin_init
• REMOTE_ADDR and forwarded-address headers
• curl_exec()
• file_get_contents()

These hooks and functions have legitimate uses. The directory, claimed identity, filenames, class, and combined hook pattern are the more useful pivots.

What this evidence does not establish

• The screenshot does not show the main or companion PHP files.
• The samples do not retain complete redirect, hide-plugin, deactivate-link, scheduling, or update methods.
• No successful redirect, target response, address transmission, or visitor impact was observed in the supplied evidence.
• No persistence after deletion was demonstrated.
• The initial access route and any vulnerable component or version are unknown.
• The evidence does not establish prevalence, campaign attribution, or a relationship to similarly named folders elsewhere.

Artifact-specific remediation

Preserve the plugin directory, relevant access logs, and scheduled-event data before removal where evidence retention matters. Verify woocommerce_inputs against the approved plugin inventory. If it is unauthorized, remove the complete folder and separately search for woocommerce-load.php, WCInputs, and the distinctive callback combination.

Review WordPress cron events and database options for identifiers tied to the plugin, but do not delete unrelated scheduled events based only on generic hook names. Compare network and access logs for behavior attributed to the artifact. Use the broader redirect malware guide for complete incident response.

Recurrence verification

• Confirm that the woocommerce_inputs directory does not return after scheduled events and normal traffic.
• Recheck the Plugins screen and direct filesystem inventory.
• Search for the two filenames, namespace, class, and callback combination across the account.
• Review logs for repeat response changes only after establishing a defensible artifact-to-request correlation.

Related malware research

• Hello Aili remote PHP loader
• PHP footer remote-content loader
• WP Security Helper plugin concealment

Methodology and privacy note

This analysis uses one privacy-reviewed screenshot and two truncated PHP samples from an anonymized investigation. The screenshot supports the directory finding only. The code summary omits site identifiers, numeric configuration values, target construction, and incomplete operational methods.