|
|
|
|
|
|
|
|
 |
Copyright © 2026 GHL News. All rights reserved |
|
|
|
Monday, June 08, 2026
Fwd: 👉 [New Releases] AskAI Blogs, Smarter AI Agents & Quiz Customization
Friday, June 05, 2026
Fwd: Someone's been living in my inbox 🥡
Monday, June 01, 2026
Fwd: Resource Usage Summary for rauterkus1
From: <support@pair.com>
Date: Mon, Jun 1, 2026 at 12:18 AM
Subject: Resource Usage Summary for rauterkus1
To: <Mark.Rauterkus@gmail.com>
CC: <mark@rauterkus.com>
This summary covers the most recent month of service, and charges have
been posted to your billing records, if any over-usage is shown below.
These charges will appear on your statement within the next few days.
This is NOT a bill, but it does represent upcoming charges.
This is an automated report generated by Pair Networks, Inc. If this
has been misdirected, please let us know at support@pair.com.
This summary covers the dates April 30, 2026, through May 30, 2026,
inclusively.
Date Bandwidth Usage
---- ---------------
Apr 30 6.87 GB
May 1 9.42 GB
May 2 20.57 GB
May 3 27.41 GB
May 4 29.63 GB
May 5 11.91 GB
May 6 13.37 GB
May 7 15.01 GB
May 8 17.59 GB
May 9 31.56 GB
May 10 33.57 GB
May 11 0 GB
May 12 35.33 GB
May 13 27.54 GB
May 14 33.31 GB
May 15 35.66 GB
May 16 30.05 GB
May 17 27.76 GB
May 18 24.96 GB
May 19 20.22 GB
May 20 19.99 GB
May 21 16.22 GB
May 22 16.85 GB
May 23 18.09 GB
May 24 34.11 GB
May 25 22.07 GB
May 26 4.75 GB
May 27 5.51 GB
May 28 0.48 GB
May 29 11.32 GB
May 30 5.59 GB
---- ---------------
TOTAL 571.05 GB
Total Bytes: 613,156,425,436 = 571 GB
Allowance: 12288 GB
This summary includes all resource usage for the most recent calendar
month. Charges for over-usage, if any, are shown above, and will appear
on your next billing statement.
1 Gigabyte (GB) is equal to 1024 Megabytes, or 1,073,741,824 bytes.
Pair Networks pricing policy is to always round down fractional Gigabyte
transfer amounts. For example, if you had a total monthly transfer of
314,159,265,358 bytes, this would be 292.583615 GB, which is rounded
down to 292 GB.
If you have any questions about your usage or this report, please contact
us at support@pair.com.
Thank you for choosing Pair Networks!
Sunday, May 31, 2026
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
.htaccessfiles, 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/GeFiles found or recreated there included:
queue_1.phpqueue_1-3.php16e2277f8b31_A16e2277f8b31_B.htaccessWordfence 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.phpmjc0.phpmjc0-2.phpmjc0-3.phpoutbound.phpdwn2.phpdwn2-2.phpdwn2-3.phpperl.haxorpy.haxorbash.haxorclass-wp-sitemaps-cache.phpImportant file behavior
The file
queue_1.phpappeared 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.phpappeared more serious. It decoded hidden numeric strings into PHP functions such asfile_put_contentsandchmod. It accepted request variables such asx1andx2and 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
.htaccessfile 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
.htaccesshardening rules.- Blocked XML-RPC where not needed.
- Blocked direct
wp-comments-post.phpwhere 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_htmlas 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.bakas 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_A16e2277f8b31_B
- Have you seen writer files using request parameters like
x1andx2to call decodedfile_put_contentsandchmod?- 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, orwp-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
Posts
