WordPress websites remain a prime target for malicious actors in the ever-evolving cybersecurity landscape. This case study delves into a perplexing incident involving a compromised WordPress website that exhibited unusual behavior, challenging the expertise of our security team.

The Challenge

Our client, a website owner, noticed that their WordPress website was displaying inappropriate and illegal content on the homepage. Upon further investigation, we discovered that the website’s main index.php file had been modified with malicious scripts, effectively replacing the legitimate content with objectionable material.

Furthermore, the .htaccess file, a crucial configuration file for Apache web servers, had been modified to disable PHP execution. This effectively prevented WordPress, a PHP-based content management system, from functioning properly. As a result, the homepage displayed only the malicious content injected into the index.php file, while the rest of the website remained inaccessible.Index-php-shows-different-size-and-permission

Initial Response and Unexpected Recurrence

As a one-time engagement, our task was to secure the website and remove the malicious content. We promptly removed the malicious scripts from the index.php file and restored the original .htaccess file, enabling PHP execution once again. Additionally, we implemented additional security measures to prevent future compromises. However, to our surprise, the malicious content reappeared almost immediately, indicating a persistent and sophisticated attack.

Deeper Investigation and Uncovering the Culprit

To uncover the source of this persistent malware, we employed a comprehensive approach:

  1. Malware Scanning: We scanned the entire website’s files using a reputable malware scanner, but it yielded no results except for the infected index.php file.
  2. WordPress Core Replacement: We replaced the WordPress core files, eliminating the possibility of malware residing within the core installation.
  3. Running PHP Processes: We examined the running PHP processes on the server and discovered a suspicious process associated with a PHP file that didn’t exist.

Shell output showing running PHP Processes and IDSince command-line access was restricted on the shared hosting server, we utilized a PHP script to identify active PHP processes by their process IDs. The screenshot above shows a running process with ID 12816, associated with icug.php. However, the file icug.php is not present on the server.
This indicated that the malware was executing code from an unseen location. Further investigation revealed that the malware was likely utilizing the file_get_contents function to retrieve malicious content from a remote server and overwrite the index.php file. This malicious activity was causing the website to display inappropriate content.

We also noticed entries in the error log suggesting that the malware was encountering difficulties in writing the malicious content to the index.php file. This was likely due to the file path being renamed during our investigation, resulting in a path change that the malware was not prepared for.
error log showing missing file error

Eliminating the Persistent Malware

We successfully halted the malicious activity by promptly terminating the suspicious PHP process using PHP script with shell_exec('kill -KILL 12816'); . This indicated that the malware was relying on this hidden PHP process to maintain its persistence and modify the index.php file, effectively hijacking the website’s functionality. We then proceeded to remove the malicious PHP file from the server, permanently disabling its ability to execute further malicious code.

Despite the website’s outdated security measures, we could not pinpoint the specific vulnerability that enabled the malware infection. Several security experts had previously attempted to eradicate the malware but were unsuccessful. Upon our intervention, we prioritized restoring the website’s functionality and mitigating the immediate threat. Considering the time and effort involved, the client opted not to pursue a detailed investigation into the infection’s origin. They were satisfied with the successful malware removal and website restoration.

Conclusion and Lessons Learned

This case study highlights the importance of a thorough and multifaceted approach to combating malware attacks. While traditional methods like file scanning and core replacement can be effective, persistent malware may require more in-depth investigations, such as examining running processes and identifying unusual file modifications.

Here are some key takeaways from this incident:

  • Maintain vigilance: Regular website monitoring and security audits are crucial for detecting and mitigating potential threats.
  • Employ multiple security tools: Utilize a combination of security tools, including scanners, firewalls, and web application vulnerability scanners, to provide a comprehensive defense against malware.
  • Investigate thoroughly: Don’t assume that removing malicious code once is enough. Investigate persistent malware thoroughly to identify and eliminate the root cause.