The hardest challenges are the ones that constantly change.

Malicious website software has recently seen an influx in self-replicating, polymorphous code that infects a website (and thus, web server) with remote code execution access to launch additional attacks and compromise the data on the breached website and server.

In a recent incident, we cleaned a website fully in a non-web environment based on a WordFence Premium scan.

After deploying this codebase to our staging environment, within seconds it became reinfected as per WordFence’s scan results as we viewed them live.

This lead us to create an NGINX configuration rule only allowing our team’s IP to access the website, in an attempt to keep the apparent “bots” from re-attacking our site with weaponized code to auto-exploit our tech stack (WordPress, PHP/MySQL, Linux – in a popular cloud provider’s single VPS).

Sadly, that also blocked WordFence from “phoning home” for updates ( as well as validation of a valid Premium license key installed, I’m sure.) This lead us to whitelist their IP range of 69.46.36.0 to 69.46.36.32. The scan ran… and boom….

More malware.

While we worked to ensure that the website was being actively analyzed for what we missed, we took a step in the direction of looking at the web server itself.

There are a few critical actions that help website intrusion incident response:

• • • Review the web server logs on Linux @ /var/log/apache2/access.log & error.log or /var/log/httpd/access.log & error.log

    • Execute the command netstat -ntap to identify all network connections. You can combine this with the watch command, such as watch "netstat -ntap" along with a terminal recorder (tools like https://asciinema.org/ are amazing for this!)
    • Perform a packet capture using tcpdump, and deploy the “most clean” version of the website we have

This gives us a great deal of information on how to act next. First, we can identify through the web server logs what URLs are being hit by a bot to trigger a re-infected, and identify the IP address of the bots hitting those URLs.

This is extremely important to document properly if there becomes a need for FBI involvement, in the case of credit card theft & identity theft.

While our systems engineers went to work on the server side of things, we continued to investigate the code base.

We blocked the IPs. Still, another re-infection.

We disabled cron. More re-infections.

But now, we were only seeing “index.php”, as well as a random PHP shell being dropped (e.g.: “wp-content/uploads/maps-backup/cnhmeiyu.php”)

Back to more code analysis. Given this site had 30+ plugins, some which were “abandoned” plugins (major red flag), we decided to look for some more common issues. Maybe we were too close to the trees to see the forest?

Using a TimThumb vulnerability scanner (a very popular vulnerability with outdated/abandoned WordPress plugins), we identified ONE vulnerable TimThumb file!

So, we patched and re-deployed, crossing our fingers…

Boom, a clean site. Next step? Snapshot backup, and on-going monitoring of the website automatically using WordPress plugins, and manually by our 24/7 network and security operation center. Continued management of the core WordPress version, plugins, vulnerability management, standing up a web application firewall, and much more are the next steps for continuing to keep this company secure.

Our team would love to hear your experience with polymorphic, self-replicating malware! E-mail us any time at [email protected] or by calling (833) SITE-FIX.

-John from SECURELI