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
No comments:
Post a Comment