At the beginning, the problem looked like a strange verification screen. Users were seeing something that looked like a Cloudflare check, but it did not behave like a normal security page. It appeared inconsistently, covered the entire screen, and raised enough suspicion that we started investigating it as a possible compromise.

That suspicion was justified.

As we looked more closely, we found that the site had been injected with malicious code. A full-screen iframe was being loaded from an unrelated external domain and displayed over the real website. In practice, that meant visitors were no longer interacting with the real page. They were seeing attacker-controlled content placed on top of it.

From there, the investigation moved to the server. We reviewed plugin files, checked recently modified code, and searched for suspicious patterns. That led to the discovery of malicious and tampered plugins inside the WordPress installation. Some of them were built to hide themselves from the plugin list, which made them harder to notice in the admin dashboard.

The most serious finding came during the user audit. There were multiple administrator accounts that had not been created by the team. The usernames followed strange patterns, used fake email addresses, and had full administrative access. One backdoor plugin was specifically designed to create an administrator account, hide it from normal views, and prevent it from being easily removed. At that point, it was clear that this was not a simple code injection. It was a persistent compromise.

Once we confirmed that, the priority shifted from investigation to containment.

We disabled and removed the malicious plugins, deleted unauthorized administrator accounts, and scanned the codebase for common malware patterns and injected payloads. We also reviewed WordPress configuration files, checked for hidden persistence mechanisms, and verified that core files and legitimate plugins were no longer serving suspicious content.

After that, we moved into recovery. Passwords were rotated, suspicious components were removed, trusted plugins were reinstalled from official sources, and additional hardening steps were planned to reduce the attack surface going forward.

By the end of the cleanup, the fake verification screen was gone, the hidden admin users had been removed, and the obvious persistence mechanisms had been eliminated. Just as important, we had a much clearer understanding of how the compromise worked and what needed to change to prevent a repeat.

This incident was a reminder that security problems rarely stay small for long. What looks like a strange front-end issue can turn out to be a deeper access and persistence problem underneath. It also reinforced a simple lesson that applies to almost every production system. Removing the visible symptom is only the beginning. Real cleanup means finding out how it got there, what it changed, and whether it left a way back in.

A few takeaways stood out clearly from this experience:

• If a site shows unexpected verification or redirect behavior, treat it seriously.
• Hidden administrator users are a major red flag.
• Unknown or tampered plugins should be assumed unsafe until proven otherwise.
• Cleaning a compromised system is not just about removing bad code. It also means removing persistence, rotating credentials, and rechecking trust in the environment.

In the end, the site was stabilized, cleaned up, and brought much closer to a secure state. More importantly, the response process itself became a useful reminder of how important careful verification is during incident handling.

Stay Safe :)