Are you protected against malware attacks?

Imagine this, one day you discover that your website is being used to propagate malware. Google adds a big red notice, alerting people that this website could be dangerous. You receive hate on social media, find it difficult getting a team able to fix the problem, all of this while your system administrator is on vacation.

At Holm Security, we provide solutions for vulnerability assessment. In meetings with our customers, we sometimes discuss previous incidents that could’ve easily been avoided. This time, we’ve decided to publish one such story, to show you what it looks like from a different perspective – from the point of view of the company owner and how it happened. This story has been described with the approval and anonymization of our customers.
Some time ago, before using Holm Security's platform, the company led by our customer (who for this article, we’ll call John) had been hacked. We know a lot of similar stories, but this specific one is a great case study for anyone making a security-related decision – and it doesn’t matter if you are a project manager at a big corporation or own a small online shop.

Your website contains malware

Let’s start with a summary of our discussion with John.

This is exactly what John saw:John probably wouldn't have been able to avoid the attack even if he had checked his phone through the night. This “red alert” was just a visible marker of something that had already happened.

John decided to start a remediation plan but quickly realized that it wasn’t as easy as he first had thought. Feeling the need to act swiftly to remove the malware from the servers, John started by contacting different pentest teams.

John's system administrator called him back after 5 hours, providing him with all the necessary information over the phone and e-mail (stating that it was not enough time to do it the proper way) and the hired team was able to start the cleanup process.

In our opinion, John should have tried to remain calm and not make emotional decisions. It’s always good to have an already predefined (and well tested) code of conduct for such cases. If John had created a risk assessment before the incident the situation where no one, except the system administrator, has access to the servers could've been quickly mitigated. Another option is to have an alternative secure communication channel.

Security is a very complex topic

While looking at application security many different aspects need to be considered. Unfortunately, auto-update itself doesn’t guarantee full protection because it’s just one single element in the whole security process. John forgot about the plugins updates, which need to be updated separately, as well as themes. Ask yourself; do you always remember to do this?
Even if it’s important to remember that such updates won’t give 100% protection. Servers, operating systems, and multiple services running (some of them accessible from the internet)– all those elements need to be regularly updated. While not all of the vulnerabilities are publicly known, there are still other risk factors; we also have to account for the human factor.
While reading this, you might get the impression that you need to hire a big team of experts (and have a big budget for that) to handle all these things - and you are right, but only partially. A lot of this critical work can be fully automated with the right tools. Holm Security is a vendor for such solutions. We provide products for continuous and automated vulnerability analysis. If you have any questions regarding our products, feel free to contact us directly.

How the attack proceeded

We reproduced the whole attack step by step- based on information provided by John; especially for you. Below we’ll present, from the attackers’ perspective, what the attack looked like. First, we’ll reproduce the 1:1 lab environment – CentOS 7, MySQL database, WordPress (in the same version), and not the updated WordPress Grace Media Player plugin.
Right, while we got this information from John the question is how did the attacker do it? The answer is straightforward, usually, it’s just enough to investigate the source code view, to find out a few tips: The biggest tip is a path to scripts and styles files (“wp-includes” and “wp-content”), which indicates the CMS type. If it’s still not enough for you, this specific CMS in the default configuration, disclosing the name + version under the “generator” meta tag.

We can call the screenshot above GAME OVER. Now it’s just enough for the attacker to open one of the provided links (for example https://www.exploit-db.com/exploits/46537) and read the instructions – especially this one:

In practice, if you add this specific URL to your website, you will get the content of the passwd file as a proof of concept (and, you can try to read other data as well):

In this specific case, the team identified some malicious files on a server (one of them was the WSO web shell), which can be easily combined with LFI vulnerability to get full access over the server. How is it possible, that such a file was stored on the server? After the log analysis phase, the team identified that it was uploaded traditionally through a file upload mechanism on one of the subpages; the root cause - as usual - was a lack of input validation. When the attacker uploaded the web shell on the server, he was able to use LFI vulnerability to run it and all he had to do, was to identify the path to the uploads folder on the server – which was easy, because of the default WordPress configuration.

This gave him a very user-friendly graphical interface with the possibility to execute any actions directly on the hacked server (regarding assigned privileges, but still there is something like Local Privilege Escalation if needed).

One more thing to do

There was still one more problem - regarding a notice from Google. To fix this, the application owner must log in to the Google Webmasters Tool and confirm that the problem is already solved. Then, Google will make a verification process, and if everything is fine now the red notice will be disabled. Such verification could take a few days – consider one thing, can your business afford this?

Our recommendations

If you are wondering how to avoid situations like this one, here is what we recommend:

• Install updates immediately (CMS, themes, plugins, servers)
• Prepare code of conduct for such emergency cases – contacts, responsible peoples, backups, etc.
• Continuously scan your application and infrastructure under secure terms (remember, that not all of the vulnerabilities are publicly known) and set up SMS/e-mail notifications.
• Validate every input from your users, on the application and server layer as well.
• Configure notifications in Google Search Console.
• Increase awareness among employees, for example by simulated phishing campaigns.