Protect / WordPress Security
Credentials, persistence, plugin exposure, file permissions and the server layer, because most WordPress compromises are not a WordPress-only problem.
TechSteps secures WordPress beyond the plugin layer: credential and account hygiene, file permissions, the server the site runs on, update discipline, and monitoring that would show a compromise rather than assume its absence. Most serious WordPress incidents are not solved by installing another security plugin.
What this solves
WordPress runs a very large share of the web, which makes it a permanent target for automated attacks. Most compromises are opportunistic rather than targeted: a scanner finds a known vulnerable plugin version and exploits it without anyone deciding to attack you specifically.
The usual response is a security plugin. Those are useful for some things and they operate inside WordPress, which is a serious limitation. A plugin cannot reliably tell you whether the server beneath it has been compromised, and it cannot protect against an attack that reaches the filesystem or database directly.
Real WordPress security is mostly unglamorous: update discipline, fewer plugins, sensible permissions, credential hygiene, a hardened server, and logs that go somewhere the attacker cannot edit.
When people call us
If more than one of these sounds familiar, the underlying cause is often a single issue rather than several separate ones.
Technical scope
Not every engagement includes all of this. The scope is agreed in writing before we start, and anything excluded is named rather than left ambiguous.
How we approach it
Securing a site that is already breached just locks the attacker inside. We check for unexpected accounts, modified core files, suspicious scheduled events and unfamiliar must-use plugins before anything else.
Every plugin and theme with its version and known vulnerabilities. Removing an unused plugin eliminates its risk permanently, which beats any amount of monitoring around it.
Dormant administrator accounts, shared logins, weak passwords and stale API keys. Account hygiene is the least interesting and most effective part of this work.
File permissions, PHP execution in uploads, configuration file protection and server hardening. This is what a security plugin cannot do for you.
A staging path and a schedule, so updating stops being a risk event that gets postponed. Deferred updates are how most WordPress sites become vulnerable.
Logging of the events that indicate compromise, stored off the host, plus a baseline so file changes are visible.
What goes wrong
These are the patterns we see most often when we are called in to fix someone else's work, or our own from earlier in our careers.
It runs inside WordPress. If the attacker reaches the filesystem or the server, the plugin is running on compromised ground and its reports cannot be trusted.
Malicious files are removed, the vulnerability remains, and the site is reinfected within weeks. The cleanup was real and the job was half done.
Commercial plugins distributed free are a common malware delivery method. This is one of the most reliable ways to compromise your own site deliberately.
A file upload vulnerability becomes remote code execution because the web server will happily run a PHP file placed in the uploads directory.
The compromise or the ransomware reaches the backups too. A backup on the affected host is not a recovery plan.
Questions we actually get asked
No. Core is developed carefully and patched quickly. Most compromises come from plugins and themes, especially outdated or abandoned ones, and from weak credentials. A WordPress site with few well-maintained plugins, current updates and strong authentication is not a soft target.
One is usually enough and none of them are the main event. They are helpful for login protection and change logging. They cannot secure the server, they cannot reliably detect a compromise that reached the filesystem, and running several together mostly adds overhead and conflicts.
Because the entry point was never closed, or persistence was left behind. Reinfection means either the original vulnerability is still exploitable, or the attacker retained access through an added account, a scheduled event, a must-use plugin or something at the server level. The cleanup addressed symptoms.
Security releases as soon as practical, ideally within days. Everything else on a regular schedule with a staging check. The pattern that causes problems is deferring updates for months because one broke something once, since the gap makes every subsequent update riskier.
It helps, particularly for blocking automated exploitation of newly disclosed vulnerabilities before you can patch. It is a layer rather than a substitute. A WAF in front of an unpatched site with weak passwords is buying time, not safety.
Describe the system and what is going wrong with it. A short technical conversation is usually enough for us to tell you whether this is the right work and roughly what it involves.