Malware You Cannot See on the Page

Why you cannot see it

Injected content is written to avoid the person most likely to remove it.

It commonly checks who is asking: showing spam pages to search engines, redirecting visitors who arrive from a search result, and serving the normal page to anybody logged in or arriving directly.

Which describes the owner precisely, since owners type the address directly and are usually signed in.

So the site looks perfect from the inside while behaving entirely differently for everybody else, sometimes for months.

What it typically does

• Serves spam pages to search engines only.
• Redirects visitors arriving from search results.
• Injects hidden links into existing pages.
• Redirects mobile visitors and not desktop ones.
• Sends spam from the server, invisibly.
• Collects what people type into forms.

The fourth is common and effective, since owners check on a desktop and a redirect affecting only phones can run for a long time before anybody mentions it.

How to actually look

The checks that defeat the cloaking, none of which take long.

Search for your own site and look at the results themselves: the titles and descriptions shown, and whether any pages appear that you did not create.

Click through from a search result rather than typing the address, since that is the condition the redirect is watching for.

Do it on a phone, on a connection that is not your office, and in a browser where you are not signed in.

Use the search console's tool for fetching a page as the search engine sees it, which shows the version served to the crawler rather than to you.

And search your own domain for terms you would never use, which surfaces injected spam pages immediately.

The signals in the figures

Since the numbers frequently show it before anybody notices anything.

A sudden increase in indexed pages, particularly pages you cannot account for.

Traffic arriving for terms unrelated to your business.

A rise in bounce rate concentrated on mobile.

Outbound mail volume higher than anything you send.

And an unexplained increase in server load or bandwidth, which the host may raise before you notice.

Any one of those has innocent explanations. Two together is worth looking properly.

A worked example

A business was told by a customer that their site had sent them somewhere else on a phone.

The owner checked immediately on his desktop, typed the address, and found nothing wrong, and assumed the customer had made a mistake.

Two weeks later a second customer said the same thing.

Checking from a search result on a phone reproduced it instantly.

The search console showed roughly four hundred indexed pages the business had never created, and the injected code had been present for about three months.

The lesson taken was that a customer report is evidence even when you cannot reproduce it, since the code is written specifically so that you cannot.

Where it hides

Useful to know, since a search for the obvious frequently finds nothing.

In theme files, particularly the ones loaded on every page.

In the database rather than in files, which most scanners look at less thoroughly.

In a plugin directory, disguised as a legitimate file with a plausible name.

In files that are not code at all, such as an image that also contains instructions.

And in scheduled tasks, which reinstall it after removal, which is why a site cleans up and returns days later.

That last one explains the most frustrating version of this and is the reason cleaning is harder than it looks.

What to do about it

Briefly, since the substance is a restore.

Take the site offline or put up a holding page rather than leaving it serving something harmful.

Change every password, including hosting, registrar, and email, since the credentials may be how they got in and will be how they return.

Restore from a copy predating the infection rather than cleaning, wherever a clean copy exists.

Update everything before it goes back up, and remove anything unused.

Then request a review if a warning has been applied, and watch the indexed page count for a fortnight.

Set up the monitoring

So that the next one is found in days rather than months.

Connect the search console and enable its notifications, which is free and reports security issues directly.

Turn on whatever file-change monitoring your host or platform offers, since the injection has to write something.

Watch the indexed page count monthly, which is one number and moves obviously when this happens.

And check the site from a search result on a phone once a month, which takes thirty seconds and is the check that catches the cloaked cases.

The reputational damage outlasts the fix

Worth understanding, since businesses assume cleaning the site ends it.

The spam pages that were indexed remain in search results for a period after removal, and anybody finding them sees your domain attached to them.

A browser warning, once applied, persists until a review is requested and completed, which takes days rather than hours.

And customers who were redirected somewhere unpleasant remember the business rather than the mechanism.

Which is the argument for the monthly thirty-second check: the difference between finding this in a week and finding it in three months is almost entirely reputational.

The counter-case

Not every oddity is malware.

Redirects on mobile can be a badly configured plugin, a caching problem, or an advertising script behaving unexpectedly.

Unfamiliar indexed pages can be legitimate ones you forgot about, or automatically generated archive pages.

Scanners also produce false positives, and businesses have paid for cleanup of code that was part of a theme.

Check properly before concluding, and where customer data or payments are involved, get help rather than diagnosing it yourself.

The checks

1. Search for your own site and read the results.
2. Click through from a result, not by typing.
3. Do it on a phone, signed out, elsewhere.
4. Fetch a page as the search engine sees it.
5. Search your domain for unrelated terms.
6. Watch the indexed page count.
7. Believe customer reports you cannot reproduce.

Step seven matters most, because the code is written specifically so the owner cannot reproduce what the customer saw.

The scripts already loading on your pages are covered in third-party scripts you forgot about.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.