Client name
redacted.

The engagement began with a narrow question about an unfamiliar PHP file in a web-accessible location. Osiris preserved the file and its metadata before changing the system, then treated it as a possible command interface rather than an isolated piece of unwanted content.

That decision expanded the investigation from one file to the surrounding WordPress application, operating system, user accounts, running processes, network activity, startup mechanisms, and other hosted properties. The response scope followed the highest confirmed level of access—not the smallest visible symptom.

Static and behavioural review showed that the file could accept instructions and manipulate the server from a web request. Its location and construction were inconsistent with the expected application, and no legitimate deployment record explained its presence.

The shell was removed from web execution and retained in restricted evidence storage. Related paths, uploads, temporary locations, neighboring sites, and account-owned files were searched for matching indicators so the response would not end with deleting the first artifact found.

WordPress checksum verification showed that distributed core files matched trusted sources. That was useful evidence, but it answered only one question. Plugins, themes, uploads, administrators, configuration, scheduled activity, and the hosting environment still required separate review.

Osiris documented this boundary clearly: application integrity can coexist with infrastructure compromise. A clean core cannot certify the operating system, privileged accounts, services, or every other application sharing the server.

An unfamiliar executable was consuming sustained processor capacity under a service account. Process details, ownership, command lines, open files, and runtime paths were recorded before intervention.

Network inspection connected the process to cryptocurrency-mining infrastructure. The outbound session and abnormal resource use established that the compromise was active, not merely historical, and gave the response team concrete states to verify after containment.

Filesystem and service-manager review found a second installation path and a startup definition designed to relaunch the miner. Enablement links and service state showed that the malicious workload could return after termination or restart.

The service definition, executable material, timestamps, and hashes were preserved. The service was then stopped, disabled, removed from automatic startup, and followed by a service-manager reload so the known persistence path could no longer restore the process.

Artifacts in temporary storage and service locations predated the suspicious PHP file by a meaningful period. Osiris used file metadata, process state, available logs, and configuration history to establish the earliest defensible evidence date.

The report separated confirmed facts from inference. It did not invent an entry route that the evidence could not prove; instead, it defined the exposure window, the credentials and applications requiring review, and the sequence of known attacker activity.

Known malicious directories, executables, service files, and the PHP shell were moved into restricted quarantine before removal from active paths. Cryptographic hashes and an evidence manifest preserved a reviewable record of what had been found and where.

The active miner was terminated and the outbound connection was checked again. Follow-up process and filesystem searches confirmed that the known executable trees were no longer active while retaining enough evidence to support the incident narrative and recovery decisions.

A browser-accessible terminal and hosting-management listeners increased consequence during the incident. The terminal was stopped, verified as no longer listening, and blocked at the firewall. Management ports without a justified public requirement were restricted.

This did not substitute obscurity for security. It reduced reachable attack surface while the deeper recovery continued and preserved administrative access through narrower, documented paths appropriate to the client’s operating needs.

Osiris verified that the miner process was absent, its known outbound connection had closed, the persistence service was inactive and no longer enabled, the terminal listener had not returned, and processor use had settled into an expected range.

These checks distinguished completed actions from intended actions. They supported a defensible statement that known malicious behaviour had been contained without overstating the trustworthiness of a system that had experienced privileged compromise.

Remote administration was moved to verified key-based access. Direct root login, password authentication, and keyboard-interactive authentication were disabled; permitted administration was narrowed and authentication attempts were reduced.

A precedence conflict initially left password authentication enabled despite the new file declaring otherwise. Osiris traced the effective value to an earlier provisioning include, corrected the load order, validated syntax, reloaded safely, and checked the resolved runtime settings again.

Credentials with plausible exposure were scheduled for rotation from a trusted device, and administrative access was reduced to the smallest necessary group. Secrets were not treated as safe simply because no direct theft could be demonstrated.

Because privileged persistence had occurred, containment could not make the existing operating system permanently trustworthy. The client received a clear distinction between a controlled transition environment and a clean long-term production baseline.

The recommended replacement would be provisioned from trusted sources with current updates, minimal services, restricted management access, monitored backups, and documented ownership. WordPress core, plugins, and themes would be installed cleanly rather than copied from the affected server.

Database content and uploads would be reviewed and migrated deliberately. Forms, integrations, scheduled tasks, email, caching, security headers, monitoring, backups, and critical user journeys would be verified before cutover, with a rollback path that did not reintroduce untrusted system components.