A compromised business-critical platform recovered, hardened, and returned to accountable operation.
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 organization discovered behavior that could not be explained by normal publishing activity. The immediate problem was availability and trust, but the deeper issue was uncertainty: the team could not reliably distinguish known-good application code from unauthorized changes, access ownership had drifted, and maintenance responsibility was fragmented.
Osiris established a controlled response sequence. We restricted exposure, captured the state needed for investigation, reviewed WordPress core, themes, plugins, users, writable locations, database content, scheduled activity, and relevant hosting access. The environment was rebuilt from trusted sources rather than treating removal of visible symptoms as completion.
After clean service was validated, administrative access and credentials were reset according to role, unnecessary software and accounts were removed, dependencies were updated, permissions and application controls were tightened, and backup and recovery assumptions were reviewed. Monitoring and a documented maintenance cadence made future change visible.
A hidden PHP file had appeared inside `wp-includes`, a directory that should match the official WordPress release. The file was approximately 22 KB and could not be explained as part of core. That location mattered: unauthorized code inside a trusted core path can blend into a large installation and may survive superficial plugin cleanup. At the same time, the public homepage was already returning HTTP 403. Osiris treated those as two facts requiring separate handling. The suspicious file demanded evidence preservation and removal; the availability condition needed to be measured before and after remediation so a pre-existing outage would not be wrongly attributed to the security work. This distinction protected both the client and the investigation.
Before changing the live environment, Osiris recorded the suspicious file’s metadata, ownership, permissions, size, type, and SHA-256 hash, then preserved a content sample for analysis. The file was moved into a timestamped quarantine outside the public document root rather than destroyed. WordPress configuration and relevant server rules were backed up separately. This created three advantages: the live application no longer loaded the unknown code, evidence remained available if later correlation was needed, and rollback information existed for legitimate configuration. Quarantine is a disciplined middle ground between leaving suspected persistence online and erasing the record of what happened.
After the hidden file was removed from the live path, WordPress core was verified against official checksums. The verification passed. That result was important, but it did not make the earlier finding harmless. Checksums validate known official files; extra files can still exist alongside them. This is why Osiris combined checksum verification with explicit searches for unexpected core additions, recently modified loaders, hidden files, and unauthorized configuration. A clean checksum result became one part of the evidence supporting recovery. It was not used as a substitute for investigating the file that should never have been present.
The audit showed that writable media storage needed a stronger execution boundary. Osiris installed both document-root and directory-local controls intended to block PHP, PHTML, PHAR, and related executable extensions under `wp-content/uploads`. Because the site ran on OpenLiteSpeed, writing a rule was not enough. The server was restarted and an origin-level test placed a temporary PHP file in uploads, requested it directly, and verified that the test token did not execute. The temporary file was removed automatically. This transformed a configuration intention into a demonstrated control. If an attacker or vulnerable plugin later writes PHP into uploads, the web server should refuse to execute it.
Osiris reviewed `wp-config.php`, preserved a backup, applied secure ownership and permissions, and ensured dashboard file editing was disabled. Disabling the built-in theme and plugin editor does not prevent every form of compromise, but it removes a convenient code-change path from an authenticated WordPress session. Administrative and hosting credentials were reviewed as part of the follow-up because file cleanup without access remediation can leave the same route available. The principle was least privilege: editors should be able to publish, administrators should have only necessary capability, and production code changes should follow a controlled deployment or maintenance process rather than ad hoc browser editing.
The public homepage returned 403 before remediation and remained 403 afterward. Osiris recorded this explicitly rather than presenting the incident cleanup as the cause of the outage or claiming that security work restored a condition it did not change. Origin tests confirmed the uploads-execution control while the public availability issue remained a separate configuration investigation. This is a small but important example of evidence-led incident response. When several problems coexist, each needs a baseline, an intervention, and validation. Otherwise technical teams can create false causal stories that make later troubleshooting harder and undermine confidence in the response.
At the end of the security sequence, the hidden PHP payload had been quarantined, official WordPress core files verified, configuration protected, dashboard code editing controlled, and executable uploads blocked at the origin. The site had a timestamped evidence location and a backup of consequential configuration. The remaining public 403 was documented as pre-existing and outside the proven effect of cleanup. This did not amount to a promise that no unknown issue could ever remain. It established a cleaner, more observable baseline from which the separate availability work and ongoing maintenance could proceed without the known hidden core artifact remaining active.
The long-term recommendation was to keep the platform inside a managed cycle: dependency review, access review, backups and recovery checks, integrity monitoring, uptime observation, performance review, and periodic searches for unexpected core files or executable content in writable paths. Material changes should be documented and verified against business-critical journeys. Security alerts should be prioritized by exploitability and consequence rather than forwarded as raw noise. The case demonstrates why Osiris combines WordPress engineering with proactive security. Recovery required knowledge of application structure, server behavior, access, configuration, and operations—not only a malware scanner.
The remediation was designed to be reversible where practical. Configuration backups were created before editing, quarantine preserved the original relative path of evidence, temporary execution tests removed themselves, and server restarts were followed by status and application checks. WordPress commands ran under the site owner rather than as unrestricted root whenever possible. These details reduce the chance that incident response creates a second outage, changes ownership in ways that later block updates, or destroys information required for follow-up. The sequence was deliberately conservative: observe, preserve, contain, change, reload, verify, and report.
Stakeholders did not need raw command output. They needed to know that an unauthorized hidden file had been isolated, official core integrity was confirmed, writable execution was blocked at origin, and the continuing public 403 predated remediation. Open questions were separated from completed work. The communication avoided claiming a root cause that evidence had not established and avoided promising that compromise could never recur. This allowed the availability investigation to continue with a trustworthy record of which security changes occurred and what those changes demonstrably affected.
The hidden payload was the immediate artifact, but the durable value came from reducing uncertainty. Trusted sources and checksums defined core, quarantine separated unknown code from production, permissions and configuration constrained change, a live test proved the uploads control, and operational reporting established ownership. Malware removal answers whether one known file is gone. Incident recovery answers whether the platform can be trusted enough to operate, whether known pathways are closed, and whether future change will be noticed. Osiris structured the engagement around the latter standard.
The next roadmap included resolving the independent 403 condition, rotating privileged credentials, reviewing all administrators and service accounts, updating supported dependencies, confirming off-site backup restoration, and placing integrity and availability signals into ongoing review. Periodic core verification would be paired with extra-file detection rather than used alone. Hosting changes would trigger a repeat of the origin uploads-execution test. This converted the case into a set of owned controls with validation criteria, giving the organization a measurable way to keep improving after emergency work ended.
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