|
|
|
|
|
|
|
|
 |
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
Friday, May 29, 2026
British Olympians Reject “Pointless” Offer To Meet Swim England Chair As Resignation Calls Grow Louder
Date: Fri, May 29, 2026 at 10:04 AM
Subject: Fwd: Olympians Reject “Pointless” Offer To Meet Swim
|
|
We Found a Backdoor: Lessons From a WordPress Intrusion
Website security is one of those topics that most people ignore until the moment they can't.
This week, I found myself deep inside a WordPress security incident that unfolded across several websites hosted on the same account. What began as a routine investigation of strange activity eventually revealed unauthorized administrator accounts, hidden files, malicious code, and a site that appeared determined to resurrect itself after deletion.
The experience reinforced several lessons that every website owner should know.
The First Signs
The initial clues were subtle.
Wordfence security scans began reporting unusual activity. Login attempts were pouring in from around the world. Some sites became difficult to access. Administrator accounts appeared that nobody remembered creating.
At first, it was tempting to believe this was merely a configuration problem. After all, security plugins can sometimes lock out legitimate users. Wordfence itself was causing some confusion as settings were adjusted and security measures were tightened.
But then came the discovery that changed the story.
Unauthorized administrator accounts appeared.
Not one.
More than one.
Deleting them did not immediately restore confidence because the obvious question remained:
How did they get there?
Following the Trail
The investigation quickly moved beyond WordPress settings.
Files that did not belong inside WordPress core directories began appearing in security scans.
Examples included:
- outbound.php
- wp-olite.php
- mjc0.php
- dwn2.php
- perl.haxor
- py.haxor
These files were located inside directories where WordPress core files normally reside.
That was a major warning sign.
WordPress core directories should contain WordPress files. They should not contain mysterious PHP scripts with odd names.
Wordfence identified twenty-three such files.
They were deleted.
The Site That Would Not Die
One website in particular, waterpolo.cloh.org, became the center of the investigation.
The infected site was renamed so it could no longer function normally.
The directory was moved out of service.
The malicious files were removed.
And yet parts of the directory structure appeared again.
A hidden .htaccess file surfaced inside a deep WordPress directory. Its purpose was clear: permit PHP execution in places where it normally should not occur.
That was a significant discovery because many malware families attempt to hide inside legitimate-looking folders and then use .htaccess files to bypass normal restrictions.
The site had effectively become untrustworthy.
At that point, the goal shifted from repair to containment.
Containment Steps
Several actions were taken immediately.
Remove Unauthorized Administrators
Every WordPress site was reviewed.
Unknown administrator accounts were deleted.
Known administrator accounts were reviewed.
Passwords were changed.
Enable Two-Factor Authentication
Administrators gained two-factor authentication.
A stolen password becomes far less useful when a second factor is required.
Rotate WordPress SALT Keys
WordPress security keys were replaced.
This forced existing login sessions to become invalid.
Anyone who had obtained a session cookie suddenly found that cookie worthless.
Change Database Passwords
Database credentials were rotated.
Fresh credentials were stored in Bitwarden.
Harden .htaccess
Additional protections were added.
Directory browsing was disabled.
XML-RPC access was blocked.
Direct comment posting was blocked.
The resulting additions looked like this:
These protections now form part of my standard WordPress hardening process.
Review Unknown Files
Security scans identified files that did not belong.
Rather than ignoring warnings, each item was investigated.
Unknown files inside WordPress core locations should never be dismissed casually.
What the Attackers Were Doing
The Wordfence live traffic screen provided a fascinating view into the reality of operating a public website.
Login attempts arrived from:
- Vietnam
- Turkey
- Lithuania
- Spain
- Brazil
- The Netherlands
- The United States
The attackers probed:
- wp-login.php
- xmlrpc.php
- wp-plain.php
They searched for known vulnerable plugins.
They tested common backdoor locations.
This activity was not targeted specifically at me.
It was automated.
Every exposed WordPress site on the internet receives similar attention.
The difference is whether the defenses hold.
An Important Realization
One of the most useful lessons from this experience was recognizing the difference between noise and evidence.
The internet is noisy.
Bots hammer login pages constantly.
Wordfence blocks many attacks every day.
Most of that activity is routine.
What changed this case was the appearance of unauthorized administrator accounts and malicious files in WordPress core directories.
Those are not normal events.
Those are evidence.
The Human Side
The process was frustrating.
Files appeared, disappeared, and reappeared.
FTP and hosting control panel views sometimes disagreed.
Security tools occasionally became obstacles themselves.
At several points it felt impossible to determine whether the problem was malware, caching, configuration mistakes, or all three.
That uncertainty may be the hardest part of dealing with a website intrusion.
You rarely receive a flashing sign that says:
"Here is the exact problem."
Instead, you collect clues.
You test theories.
You eliminate possibilities.
Eventually a picture emerges.
The Final Lesson
The biggest takeaway from this experience is simple.
Security is not a product.
It is a process.
No plugin can completely protect a website whose passwords are weak.
No password can completely protect a site running vulnerable software.
No scan can protect a site that nobody reviews.
Security comes from layers:
- Strong passwords
- Password managers
- Two-factor authentication
- Software updates
- Security monitoring
- Regular reviews of administrator accounts
- Backups
- Healthy skepticism
Most website owners will never face a major compromise.
But if they do, preparation matters.
The best time to improve security is before you need it.
The second-best time is tonight.
Posts
