`base64_decode`, `eval` or `gzinflate` are investigation signals, not automatic proof that a PHP file is malicious. Some legitimate software ships encoded or generated code. Preserve the file, establish its provenance and compare it with a trusted release before deleting anything.
Record file identity before touching it
Save path, owner, permissions, modification time and a cryptographic hash. This gives you a stable artefact even if a later cleanup or deployment replaces the file.
Establish expected provenance
Ask which plugin, theme, dependency or custom deploy owns the path. Compare the exact installed version with a clean vendor package or source-controlled release.
Inspect suspicious transformations safely
Read encoded strings as data and decode them in an isolated analysis context; do not execute unknown payloads simply to see what they do. Look for unexpected remote loading, credential access or write behavior.
Trace how the file is reached
A suspicious helper that is never loaded is a different incident from code included on every request. Follow includes, hooks and bootstrap paths to understand exposure.
Search for related artefacts by evidence
Use distinctive strings, hashes, timestamps or paths to find siblings. Avoid deleting every file containing a common PHP function name.
Replace from a trusted source and retest
When malicious modification is confirmed, restore the owning component from a known-good release and then verify functionality plus absence of the identified indicators.
Start with the safe obfuscated-PHP review and preserve artefacts using the evidence guide.