From repeated compromise symptoms to a controlled, maintainable WordPress operating baseline.
Osiris protects the confidentiality of security clients. The organization’s name, domain, dates, vendors, personnel, and sensitive indicators are redacted or generalized. The account below explains the work without publishing details that could expose the client or its environment.
The production website showed recurring signs of unauthorized modification. Previous cleanup attempts had addressed what visitors could see, but the environment still contained uncertainty around custom code, outdated dependencies, administrator access, and the path by which changes reached production. The organization needed more than another cosmetic cleanup.
Osiris separated containment from recovery. We reviewed the application and infrastructure layers, identified components that could not be trusted, preserved necessary business content, and reconstructed the platform using verified WordPress sources and reviewed custom functionality. Critical forms, redirects, content workflows, and integrations were tested before public service was normalized.
The recovered platform received a smaller software footprint, least-privilege administration, controlled update procedures, stronger file and account governance, monitored backups, uptime and integrity observation, and clear escalation ownership. Technical documentation recorded the new baseline so later changes could be evaluated against a known state.
The initial scan reported a modified WordPress core interface file, an unknown `feo2` artifact, multiple `kzb9` PHP variants inside a core contracts directory, a non-core `.render-cache` directory, a modified root `index.php`, an `index.php.nox-bak` file, an unknown `wp-comments-post-loader.php`, and a modified file inside the WPvivid backup plugin’s Monolog library. Any single discrepancy might require context. Together, modified loaders, extra PHP files inside core, a backup-named artifact, and a plugin vendor-file change created a high-confidence need for containment and reconstruction. Osiris treated the scanner email as an intake signal, not a remediation plan.
The response began with a timestamped evidence and backup structure. File metadata and hashes were retained for suspicious artifacts, and consequential configuration was copied before remediation. This mattered because the unknown files were distributed across root, core, a generated-looking directory, and a vendor library. Deleting only the most obvious loader could have removed the visible symptom while leaving another persistence point. Evidence preservation also made it possible to distinguish malicious modification from expected WordPress or plugin behavior and to explain why each live file was removed, replaced, or retained.
Modified official files and unexpected additions inside `wp-includes` meant that individual editing was not the safest recovery strategy. Osiris identified the installed WordPress version, obtained the matching official release, and used it as the trusted source for core reconstruction. Compromised core directories were retained outside the public path as evidence before clean directories were installed with correct ownership and permissions. Extra files were explicitly quarantined because copying official files over the installation would not remove unauthorized additions. Final checksum verification demonstrated that live core matched the official release after reconstruction.
The modified WPvivid vendor file could not be assumed safe merely because it lived inside a legitimate backup plugin. Vendor libraries are useful hiding places because administrators expect many unfamiliar files. Osiris compared the component against a trusted plugin source and treated replacement of affected plugin code separately from core repair. Backup capability was reviewed before altering the plugin because incident recovery depends on retaining trustworthy restore options. This balanced two needs: removing a potentially modified execution path and avoiding careless destruction of the client’s recovery tooling or archives.
The root loader, NOX-style backup filename, `kzb9` variants, unknown executable artifacts, and non-core cache directory were handled as live trust failures. High-confidence files were quarantined with their relative paths preserved. The response also searched for related filenames, must-use plugins, PHP-like files in uploads, unauthorized `.htaccess` files, scheduled tasks, and database indicators. That wider search addressed the possibility that the scanner listed only a subset of the compromise. A successful incident response cannot depend on one vendor’s signatures; it needs to examine the pathways by which code can be loaded, rewritten, scheduled, or served conditionally.
After reconstruction, Osiris disabled dashboard code editing, protected sensitive configuration, corrected ownership and file permissions, and installed controls to prevent PHP execution from uploads. On the OpenLiteSpeed environment, controls were verified by requesting a temporary executable at the public path and confirming it did not run after server reload. The homepage and critical public behavior were checked so hardening would not quietly break production. These steps reduced the chance that a future vulnerable upload or stolen administrator session could recreate the same easy execution path.
Recovery validation included official core checksums, plugin review, live homepage status, uploads execution testing, examination of administrators and application passwords, and review of recent or unexpected files. Normal and crawler-facing responses were considered where search spam or cloaking could have been part of the compromise. Each control was evaluated in the environment that actually served the site. The result was a known baseline supported by evidence: trusted core, reviewed plugin code, quarantined extras, restricted writable execution, controlled administration, and documented configuration backups.
The most important long-term change was explicit ownership. The organization moved from reacting to scanner emails toward a repeatable security maintenance process. Dependencies, privileged access, backups, integrity, uptime, and performance received named review. Future findings could be compared against the recorded baseline rather than investigated from scratch. Quarantine retention and change records supported later analysis without leaving suspicious code accessible. The case shows that a complex WordPress compromise is not a collection of files to delete; it is a failure of trust that must be rebuilt across application, infrastructure, access, recovery, and ongoing stewardship.
Modified `index.php`, the NOX-style backup, and the comments-post loader sat in locations likely to receive or influence requests. Their names could resemble legitimate bootstrapping or backup behavior, which is precisely why context and source comparison mattered. Osiris did not normalize them because the site still loaded. The files were mapped to their execution role, preserved, and removed from production. Root entry points received special validation after reconstruction because a clean `wp-includes` directory cannot compensate for an unauthorized loader that runs before or alongside normal WordPress bootstrap.
The `.render-cache` directory did not belong to the official WordPress release. Generated directories can be legitimate, so the name alone was not sufficient evidence. Osiris reviewed ownership, timestamps, file types, references, and whether any active component documented its use. In the context of multiple unknown PHP artifacts and modified entry files, unexplained executable or loader content could not remain inside the public application. The live directory was quarantined and the recovered site was observed for any legitimate dependency. No unexplained directory should receive permanent trust merely because its name sounds operational.
After technical recovery, the team verified more than the homepage. Representative content templates, navigation, search, forms, redirects, media, administrator publishing, cache behavior, and connected services were checked. This protected the business from a different kind of failure: a technically clean WordPress installation that could no longer support essential work. Recovery sign-off combined integrity and usability. Documentation recorded what was replaced, what was retained, where evidence lived, which credentials or components still needed owner action, and how the new baseline would be monitored.
The case informed how Osiris approaches custom WordPress engineering. Plugins and themes should have traceable sources, controlled deployments, explicit owners, scoped privileges, and an update strategy. Writable locations should not execute application code. Backup plugins and vendor libraries should be included in integrity review rather than assumed safe. Logs and monitoring should make unexpected loaders and core additions visible. Security requirements belong in the development definition of done, because architecture and operational choices determine how difficult an incident will be to detect, contain, and recover from later.
BeforeUntrusted application state
Unclear access ownership
Reactive cleanup
Untested recovery assumptions
AfterValidated clean baseline
Controlled administration
Managed maintenance
Observed recovery posture
No responsible provider can promise that a connected system will never be compromised. The result is reduced likelihood, reduced impact, clearer ownership, and a practiced response when conditions change.
Bring us the platform that needs stronger engineering, tighter security, or a clear technical owner.
Start a conversation