Memo to Wordfence folks - Malware Samples and Reappearing WordPress File Writer: Have You Seen This Pattern?

Request for Guidance: Persistent WordPress Malware Reinfection and Reappearing File Writer

Hello Wordfence Team,
I am writing to document a difficult, ongoing WordPress security incident and to ask whether your team has seen this pattern before.
I am the webmaster for multiple small nonprofit, sports, coaching, and community websites hosted under a Pair Networks account, rauterkus1. I use Wordfence on a number of these WordPress sites. Wordfence has helped identify many of the bad files, but the larger issue is that some malware directories and files are reappearing after deletion. I am trying to move from cleanup mode to root-cause mode.
I would be open to a phone conversation if someone at Wordfence is interested. I can also supply more detail, saved files, logs, screenshots, and possibly a backup/archive for inspection. Forensics is not my strength, but I have preserved some useful evidence.
Summary of the incident
This began as what looked like a normal WordPress malware cleanup: Wordfence alerts, unknown files in core locations, modified core files, suspicious .htaccess files, and unauthorized WordPress administrator accounts.
However, the situation became more serious because after deleting malware files, certain directories and files reappeared.
The most important recurring infection path has been:
/usr/home/rauterkus1/public_html/waterpolo.cloh.org/wp-includes/sodium_compat/src/Core32/Curve25519/Ge
Files found or recreated there included:
queue_1.php
queue_1-3.php
16e2277f8b31_A
16e2277f8b31_B
.htaccess
Wordfence also found other unknown files in WordPress core locations, including examples under:
wp-includes/sodium_compat/
wp-admin/css/colors/sunrise/
wp-admin/maint/
wp-includes/certificates/KINGSMAN/
wp-includes/sitemaps/providers/
Some file names reported or observed included:
wp-olite.php
mjc0.php
mjc0-2.php
mjc0-3.php
outbound.php
dwn2.php
dwn2-2.php
dwn2-3.php
perl.haxor
py.haxor
bash.haxor
class-wp-sitemaps-cache.php
Important file behavior
The file queue_1.php appeared to start a PHP session, accept data from a request, store it in session data, and rename itself using the session ID and session path.
The file queue_1-3.php appeared more serious. It decoded hidden numeric strings into PHP functions such as file_put_contents and chmod. It accepted request variables such as x1 and x2 and appeared able to write arbitrary files.
That seems to explain why deleting visible files is not sufficient. If any web-callable copy of this writer remains reachable, a bot or attacker may be able to recreate the malware tree.
A local .htaccess file inside the infected folder included rules that allowed PHP files to execute from that deep location. In other words, the folder appeared to be prepared as an executable hideout, not merely a storage location.
What we have done so far
We have taken many containment and cleanup steps:
Deleted unauthorized WordPress administrator accounts.
Changed WordPress admin passwords.
Rotated WordPress SALT keys on affected sites.
Changed database passwords on some affected sites.
Reinstalled or reactivated Wordfence on multiple sites.
Used Wordfence to delete flagged unknown core files.
Added .htaccess hardening rules.
Blocked XML-RPC where not needed.
Blocked direct wp-comments-post.php where comments are not used.
Disabled or retired unneeded sites where possible.
Moved some mission-critical sites away from the compromised environment.
Nuked all old FTP accounts and plan to recreate only temporary, limited access accounts as needed.
Began inspecting raw logs from Pair Networks.
Kept some suspicious files and screenshots for evidence.
Complicating factor: web root disruption
During the response, the main web directory structure became disrupted. Many sites that had been under:
/usr/home/rauterkus1/public_html/
ended up under:
/usr/home/rauterkus1/public_html/public_html.bak/
Pair Networks has said they only renamed public_html as a test and did not restore a backup. They also said that any available backups may already be compromised.
The current working approach is not to restore the entire old tree blindly. We are treating public_html.bak as contaminated source material, not as trusted clean backup.
Host observations
Pair Networks reported that the suspicious files were being written as my account user. They did not see active cron jobs, SSH logins, or obvious FTP logins from unknown IPs in the basic account access records. FTP logins that were shown came from my own IP address. That does not rule out web-executed malware, compromised local credentials, or a surviving PHP writer elsewhere under the account.
The recurring theory is that a surviving web-callable PHP writer, possibly in another WordPress install or old site folder, is recreating the malware tree.
Questions for Wordfence
Have you seen this specific pattern before?
In particular:
Have you seen malware hiding under paths like:
wp-includes/sodium_compat/src/Core32/Curve25519/Ge
Have you seen payload pairs like:
16e2277f8b31_A
16e2277f8b31_B
Have you seen writer files using request parameters like x1 and x2 to call decoded file_put_contents and chmod?
Is this associated with a known malware family, campaign, or exploit chain?
Is there a recommended way to search across an entire hosting account for related writer/dropper files, not just one WordPress installation?
Can Wordfence scan outside the normal WordPress directory if multiple WordPress sites share one hosting account?
Is there a Wordfence-supported method to identify the original vulnerable plugin, theme, upload folder, or entry point?
Are there specific log patterns I should search for in raw Apache logs, such as POST requests to unusual PHP files under wp-includes, wp-content/uploads, or wp-admin?
What should I preserve before continuing cleanup?
Is this the kind of case where Wordfence Care or Wordfence Response would normally be appropriate, even if I am first seeking guidance or an estimate?
Help requested
I am not expecting free emergency remediation, but I am asking for guidance.
I would appreciate knowing:
Whether this pattern is familiar to your team.
Whether specific file names or paths indicate a known malware family.
Whether there are recommended searches or YARA-like signatures I should run.
Whether Wordfence has documentation for multi-site shared-hosting reinfection loops.
Whether you can suggest a safer sequence for cleanup, scanning, and password rotation.
Whether someone at Wordfence would be willing to review a small sample set of files.
Whether you offer an estimate or bid for this type of incident review.
I am also open to suggestions about other security professionals or tools that may help. If there is a more specialized forensic GPT, scanner, or incident-response workflow you recommend for WordPress malware on shared hosting, I would be interested.
Current status
This is still a work in progress.
Some sites have been stabilized. ACEN has been temporarily redirected to a clean Pairsite location. SwimISCA.org has been moved to a different server. Blog.SwimISCA.org was restored after fixing a missing PHP 8.4 wrapper. FTP accounts have been removed. Raw logs are being gathered.
The key unresolved issue is identifying and eliminating the surviving writer or entry point that caused malware files to reappear after deletion.
Thank you for any guidance you can provide.
Sincerely,
Mark Rauterkus