At Malcure we come across many types of web-malware on a daily basis. In one of the recent tickets, we found the site was being injected with spam.
The Google SERPS (search results) also mentioned the infamous message “This site may be hacked.”
First scan in, there didn’t seem to be anything suspicious prima facie.
Table of Contents
Why no malware detected in the initial scan?
At Malcure we use multiple scan methods. But malware is often able to escape initial detection due to how various scanners work.
How web malware scanners work
Based on the access type, malware scanners can be classified primarily into two types:
- Web-based malware scanners: Web-based malware scanners crawl the website, the pages of the website including other resources included in the website. They work just like search-engine bots like Googlebot or Bingbot. Now just like a normal visitor doesn’t have access to the backend of the website, these web-based malware scanners can also only access the public facing pages and resources. Other server-sides scripts, password-protected resources are not accessible and thus web-based malware scanners often fail to detect something that’s hidden on the server-side, in scripts and other files like backdoors etc.
- Server-side malware scanners: Server-side malware scanners are essentially software scanners that are installed on the webhosting server and are able to scan files and / or databases. This means they have access to the data on the server instead of just being limited to publicly accessible resources. Server-side scanners are smarter and scan deeper.
As far as reliability of infection-detection is concerned, there are only a handful of web-malware-scanners. When infection clean-up is concerned, we rely on server-side scanners because of the advantages they bring in.
Detection methods in server-side malware scanners
Server-side scanners can be generic or specialized to work only with specific CMS systems. They work based on a combination of checksum matching, pattern-detection etc. or a hybrid-combination of these.
A truly ingenious malware like this one would try to escape all detection methods. Not that it’s undetectable, but just that the scanners haven’t caught up with the signatures yet.
Typically the malware is injected in a file by some method (let’s just say a nulled theme or plugin). At other times the malware could be injected into the database which is then rendered on the public facing pages.
Typically for an end-user or webmaster these infections may not be as obvious as malware may hide in post meta information which is not visible to the bare naked eye.
Both these malware injections are easily detectable with server-side scanning. But a hybrid-complex infection approach warrants some more in-depth analysis of what’s going on.
While searching all files for unknown malware signatures or manual inspection would just take too long and is hit-and-trial at best, we decided to look for common suspicious code inside the database itself.
What is suspicious code?
Suspicious code for the sake of malware detection is any code that is indirectly trying to do something which could be done simply and directly.
could simply be written as
So the intention of the code is suspect.
Finding the Hybrid Complex Database File Infection
Well, the fist common suspects are calls like
base64_*. So we started with
The code looks like this; note the call to
Well, time to decode it.
This code was inside the
wp_options table of the WordPress database, the option name being
theme_css. The db infection signature can be found here. Something ought to trigger else by itself, this code wouldn’t create the ruckus. A quick
grep later, this showed up:
The file infection signature can be found here. Eventually this code would hook into
wp_footer using the hook
wp and fetch content using
wp_remote_get would inject a script at run-time like:
A hex decoder would decode
\x55 and other gibberish into the following which makes the functionality obvious to the naked eye:
Impact of This WordPress Malware Infection
This WordPress malware would eventually inject spam into the page thereby stealing the search ranks of the website.
Since Google detected this and reported the site mentioning “This site may be hacked”, webmasters and website owners having integration of the site with Google Search console would also see this security issue listed in GSC and the site flagged under Security & Manual Actions.
You may also notice other Google notifications in Google Search Console like “Deceptive Site ahead”, “This site may harm your computer“, “The site ahead contains harmful programs”, etc.
By the very nature of spam infection, cleaning up the site does little to your SEO immediately. It takes time for Google and other search-engines to reindex the changes and fix the website ranks.
If you need help with restoring your hacked site, please create a ticket with us and out dedicated incident response team will ensure that your website is 100% clean and secure.