cPanel PHP Cron eval Wrapper Persistence Research

Artifact class Server cron encoded PHP execution

Evidence confidence High

Risk assessment Critical

Start with the problem you are seeing

Could this match the problem on your WordPress site?

This entry helps owners investigate recurring suspicious files or behavior when a hosting-level cron task survives normal WordPress cleanup. The retained cron command ran hourly and invoked decoded PHP, although its complete payload effect is unknown.

Observed in this investigation

The retained server cron entry ran hourly and invoked an encoded PHP command outside the normal WordPress scheduler.

Possible warning signs

A removed artifact may return on an hourly cycle if the cron command recreates or reloads it.
Cleaning WordPress files alone may leave the hosting-level scheduled task untouched.

These signs are investigation leads, not proof of this artifact by themselves.

Questions this research can help answer

Why does WordPress malware return every hour after cleanup?
Can a server cron job reinfect a site outside WP-Cron?

Evidence boundary: The schedule and encoded invocation are confirmed; the retained evidence does not show the full payload outcome.

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.

Ask me to investigate your site See how my malware cleanup works

Research focus: Forensic analysis of an hourly cPanel cron command that invoked php -r with an eval, gzinflate, and base64_decode wrapper.

Summary

This WordPress malware research entry documents server cron encoded php execution evidence observed during one anonymized client investigation. The narrow topic is Hourly cPanel PHP Cron Job Running an Encoded eval Wrapper: the page records the exact artifact, identifiers, and visible control flow instead of repeating a general malware-removal article.

The hourly schedule provides a plausible mechanism for recurring reinfection after visible files are cleaned. What the embedded payload created cannot be confirmed without safely decoding and correlating the private sample.

Investigation context

Anonymized investigation with cPanel and shell screenshots plus a retained cron command; screenshots exposing client identity or a full payload are excluded. 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

The public entry does not use a screenshot because the retained images either exposed sensitive values, showed a complete encoded payload, or did not add reliable evidence beyond the supplied code.

Confirmed findings

The cron schedule runs at minute zero with wildcard hour, day, month, and weekday fields.
The command invokes /usr/local/bin/php -r.
The inline PHP uses eval(gzinflate(base64_decode(…))).

Technical analysis

Why the scheduler is a persistence clue

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

0 * * * * /usr/local/bin/php -r '
  eval(gzinflate(base64_decode("[REDACTED ENCODED PAYLOAD]")));
'

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

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

/usr/local/bin/php -r with the nested eval wrapper
Hourly 0 * * * * schedule
The exact wrapper stored as a cron command

Contextual indicators

Cron job
base64_decode()
gzinflate()
eval()

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

The decoded payload is not published or characterized.
The evidence does not establish which files the cron job created.
The initial creation of the cron entry and any redirect outcome were not confirmed from retained logs.
Screenshots with client names, usernames, and full payloads are excluded.

Artifact-specific remediation

Preserve the cron entry and full payload privately.
Remove the unauthorized scheduler entry and review all user and system cron locations.
Search files and logs for artifacts created around the hourly execution time.
Rotate hosting credentials if cron access was unauthorized.

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

Re-list cPanel and shell crontabs after cleanup.
Monitor process and file changes around the top of each hour.
Confirm the encoded wrapper and related tasks do not return.

Browse the WordPress malware research hub.

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.

Hourly cPanel PHP Cron Job Running an Encoded eval Wrapper