Student Shelter In Computers
Slogan : Our Aim & Mission as a Organization to Promote Information Technology , Cyber Secuirty , Entrepreneurship Education into Young Generation , Teach , Train & Employee them in Eduction Sector , Banks & Different Industries and Bulid them Future Leaders.

Malicious Google Search Console Verifications

This past summer we noticed a trend of more and more Blackhat SEO hacks trying to verify additional accounts as owners of compromised sites in Google Search Console (formerly Webmaster Tools).

Google Search Console provides really useful information and tools to webmasters who want to:

Know how their websites perform in search results.

Receive notification about performance, configuration and security issues.

Efficiently troubleshoot Search Engine Optimization (SEO) issues.

There’s really no reason why someone wouldn’t register their site there. It contains beneficial information for anyone who wants their website indexed by Google. Hackers realize this and try to get access to the Search Console for websites they hack, especially when they add their own spammy content and technically are (malicious) webmasters.

For example, this was found in a template of one pharma doorway generator:

<meta name="verify-v1" content="JxC+bn8NTCEfKZIdusC9WQELc8FEwbi8p32wf9q0QGA=">

This line of code allows hackers to verify site ownership of compromised sites.

Using Google verification meta tags is just one of many approaches that hackers use. In this post, we’ll show some other (more sophisticated) tricks and talk about the outcomes of such hacks.

Why Verify Ownership For Hacked Sites?

First of all, you should realize that verifying ownership of a site in Search Console doesn’t make you a real site owner. It’s just a way to demonstrate to Google that you control the site. There are multiple ways to do this – you can prove you have access to the website file server, control the domain DNS records, or a related Google service like Analytics. Once you have verified your access to the website as an administrator elsewhere, Google will show you information intended for the site owner. You can also do some things that can affect the way Google indexes the site and shows in their search results.

You should also realize that Google allows a website to have multiple owners (e.g. a real owner and another webmaster may be verified as owners, plus a third-party SEO specialists might need full “owner” permissions while they work on the site). Each owner verifies themselves individually and adds websites to their own Search Console. If hackers verify themselves as owners of your site it does NOT mean that Search Console (or your Google account) is hacked.

So why do they do it?

Well, I can only guess, but there are several things that hackers may use Search Console to accomplish:

1. Gather statistics that can tell them how their black-hat SEO campaign performs: clicks, impressions, CTR, positions in Google search results and other goodness from the “Search Analytics” section.

2. Submit sitemaps of their spammy pages to have Google quickly discover them all, meaning they don’t have to wait for Google to discover the pages via links on other sites. Hackers might even think that Google will treat their spam pages as legitimate when they are submitted as part of a sitemap directly from a verified site owner.

3. Get notifications about hack detection. This may help estimate how efficiently Google can detect their doorways and the amount of damage it does to their campaign.

4. Unverify legitimate site owners’ accounts so that they don’t receive any notifications (e.g. about security issues) from Google Search Console.

Let’s focus on the last point and see what happens when someone adds a new owner to a site in Search Console and when someone removes other site owners (unverifies their accounts).

New Owner Notification

When someone verifies a new Google account as a site owner, all existing site owners immediately receive a notification email telling them, “Google has identified that [email protected] has been added as an owner of Search Console account for http://www.example.com“. This email also warns that only relevant people should have this access and provides with useful links to let you manage existing users and their permission levels.

Search Console New Owner Notification

So far so good. If hackers add themselves as owners of your site you’ll be immediately notified and can quickly investigate and resolve the security issue (unverify their account, estimate damage, clean up your site, close security holes, etc). That’s really great and helpful Google. Thank you!

Unverifying Legitimate Owners is Easy

What if you missed that email?

Say you were on a vacation at that moment and when you returned the email was lost in a backlog of unread emails where it may linger for months… This scenario gives hackers time that they can use, say, to unverify your own account so that you don’t receive any new notifications about the site (for example, when Google detects security issues caused by the hack). Can you guess what else? You will not receive any notifications from Google that you are no longer an owner of your site in Search Console.

If you rarely log into Search Console, you will have no idea that you no longer have access to your site data there.

Now let’s imagine the following scenario: Google detects the hack and notifies site owners about it. Only the hackers will receive this notification. The real site owner still doesn’t even know about the hack and doesn’t do anything to clean the site. This gives hackers time to mitigate the issue in their favor. Say, they can temporarily remove their doorways and request a review from Google. When the Google Web Spam team finds no doorways, they unblock the site and notify the site owners (in our case the hackers) about it via Search Console. After this notification, the hackers simply restore their spammy pages (maybe using slightly different URL pattern) and continue exploiting resources of the hacked site.

WNC-582900

Let’s step back from speculations into the real world. Do hackers really verify themselves as site owners in Google Search Console? The answer is yes. The Google “new owner” notification emails help us prove it. The last sentence in that email says:

Ask questions in our forum for more help – mention message type [WNC-582900].

People do ask questions in Google Webmaster Forum mentioning this message type, most of which are related to site hacks.

Multiple New Owners

Typically hackers add more than one “owner” account. This thread mentions 2 new verified owners. Another webmaster reports receiving about 30 new “verified” owners notifications in just one day. One other webmaster shares a screenshot of the “Verified owners” section of their Search Console with over a hundred entries (extrapolation based on the size and position of a scrollbar on that screenshot).

So it’s started by yesterday evening, where I received a lot of [WNC-582900] new owner notification message, and after that, when I checked my site owners, I had a LOT of listed owners!

Here are just a few of the email addressed that hackers used in Search Console:

elsuperwhite @gmail.com

haolinliner @gmail.com

definitevvdp @gmail.com

josephig6aef @gmail.com

HTML File Verification

The most popular site verification method is using special HTML files with names like google[code].html and the following content:

google-site-verification: google<code>.html

In the example, code is a unique 15-digit hexadecimal number associated with a user’s Google account. This one file can be used to verify multiple sites.

When hackers get access to a website, it’s easy for them to create this file and verify themselves as an owner.

Here is some further evidence from the forum:

Search Console Account Hacked: “An HTML verification file is being placed on my server in the root directory. I am not placing it there, and it’s not being placed there using my FTP account.”

Unauthorized verification of webmaster owners: “And in my site’s file manager, I spotted these whole verification HTML files just created recently, and I have deleted those unknown files.“

Usually these files are being uploaded via vulnerabilities in web applications or via backdoors that hackers install after breaking into websites. That’s why deleting the file and changing FTP passwords is usually not enough:

So it happened 2x more overnight. I’ve reviewed all the logs on my end and the audit trails show it wasn’t my account that was compromised – the only actions in the server FTP that I can see are the ones I’ve done.

Mysterious Verification Files

To unverify these malicious “owners” you need to remove the files (meta tags, DNS records) that they used for their verification. However, it’s not always as easy as deleting an HTML file.

There are quite a few cases when webmasters received notifications about new site owners and the “Verified Owners” section of Search Console clearly showed which HTML files were used for their verification, but it was not possible to find and delete the files on server. Despite of the absence of the verification files, Google refused to unverify the malicious owners because somehow the files were visible when you tried to open them in a browser.

hackerata proprietà del mio sito (ownership of my site hacked): “Should I remove it, but going to FTP to my site this HTML file there is neither the root nor elsewhere.” (Google auto translation).

message type [WNC-582900]. Unauthorized owner has gotten verification – HOW?: “I have worked all day with the web site host and the FILE IS NOT found anywhere on my web site. …I cannot unverify this hacker – Google keeps giving me the message that the “Verification File Still Exists” — BUT IT DOES NOT.“

Hoax email from sc-noreply @google.com (allegedly Google Search Console Team): “Further, there is no “verification file” that is cited on the “console” within the root directory of the relevant directory on the server.“

In the last case, the webmaster doesn’t even believe the notifications were real (despite the fact that he saw those new “owners” in his Search Console). Since that disbelief was posted on his website for public access, I guess he wouldn’t mind if I publicly explain why those emails were authentic, his site was hacked, and why he couldn’t find the verification files.

First of all, Google indeed uses the “sc-noreply @google.com” email address for Search Console notification emails. But they began using it only after the May rebranding of Webmaster Tools. This explains why you don’t see many references to it on the web.

Japanese SEO Spam

In our experience, verifying site ownership is currently mainly used in attacks that create tons of spammy doorway pages in Japanese (we see tens of thousands of affected sites, with over a billion created doorways). They work in a niche of “cheap/fake brand goods” so you can normally detect them if you search your site for keywords like “louboutin“, “gucci“, “louis vuitton“, “moncler“, “ray ban“, etc. So the first thing I did when came across that blog post was search the site for the Japanese SEO spam. Sure enough, I found it there.

Japanese spam in search results.

Having found the Japanese spam, I knew exactly why the webmaster couldn’t find the verification files. This attack uses quite a smart approach to Google verification that’s worth a detailed review:

.htaccess Rewrite Rules

The attackers upload a PHP script that generates doorways to some subdirectory, and then add rewrite rules to .htaccess files to make the spammy URLs look a bit more legitimate – like they are at a site top level, in some cases like static .html pages, etc. Among those doorway rewrite rules, they also add a specific rewrite rule for Google verification files:

... RewriteRule ^([0-9]+)/(.*)-(.*)-([0-9]+)\.html$ wp-content/file.php?uu=$2-$3-$4 [L] RewriteRule ^([0-9]+)/google(.*)\.html$ wp-content/file.php?google=$2 [L] RewriteRule ^(.*)-(.*)-([0-9]+)\.html$ wp-content/file.php?uu=$1-$2-$3 [L] ...

As you can see, the second rule matches the format of Google verification file names and rewrites the requests to a malicious script file.php with a “google” parameter, whose value equals to a unique Search Console ID of the requested verification file. This rule will work for any requested Google verification file regardless of its name. So if someone try to open http:// www. example. com/dir/google77aa6bc3a2973942.html, behind the scenes, the server will open http:// www. example. com/wp-content/file.php?google=77aa6bc3a2973942.

Multiple Representations of the Same Site in Google Search Console

Please note, that this .htaccess file expects that Google will be requesting the verification file in some sub-directory, not at the root level. That’s not a mistake. Google actually allows you to verify ownership of various sections and versions of the same site. For example, you can separately add the following to your Search Console account:

http:// example.com

http:// www. example.com

https:// example.com

https:// www. example.com

http:// example.com/blog/

etc.

Although it’s technically the same site, each of them require a separate verification. In our case, hackers were specifically interested in verifying ownership of subdirectories they created for their spam campaign.

Dynamic Verification File Generation

Now let’s see how the file.php script works.

Doorway script with Google verification code

Doorway script with Google verification file

It’s a typical doorway script that returns spammy pages to Googlebot and redirects the rest of the visitors. The interesting part is the last four lines of code. This script dynamically generates the typical (and 100% valid) content of a Google verification file.

Let’s return to our example, where .htaccess rewrite rule requested the file.php?google=77aa6bc3a2973942 page. In this case, the server response will be:

google-site-verification: google77aa6bc3a2973942.html

That’s exactly what Google expects to see when verifying ownership.

This trick makes it difficult to find and delete the verification files if a real site owner wants to unverify the hackers’ accounts. At the same time, this is a very flexible approach for the attacker, as it doesn’t need to stick to any specific Google account. They can use any Google account, or however many accounts they like to verify ownership. If one account is disabled, they don’t have to change anything on the server to verify a different account.

A similar .htaccess trick was found in one of the above-mentioned forum threads:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^([a-zA-Z0-9_-]+).html$ wp-includes/themes/good/$1.php [L]
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Here, Google verification file URLs are being rewritten to PHP files with the same names inside the wp-includes/themes/good/ folder. E.g. in case of our previous example, it would be wp-includes/themes/good/google77aa6bc3a2973942.php.

This approach also hides the verification files from users, but it’s a less flexible solution as it requires existence of a google[code].php file on server. In this case, hackers can only verify some pre-defined accounts for which they already uploaded verification files. Most likely it’s an older version of the same attack.

To Webmasters

Verification of malicious users as site owners in Google Search Console is a relatively new phenomenon and it’s still not clear if this is something that hackers will adopt as a useful tool in their arsenal or abandon as something of questionable value. In either case, site owners should be prepared for such attacks and even take advantage of the Google’s notification system.

1. Please make sure you registered and verified ownership of all your sites (including subdomains) inGoogle Search Console. If someone else tries to verify ownership of your sites (or sections of your sites), you’ll immediately receive a notification from Google and will be able to quickly mitigate the issue. If you don’t add your sites to Google Search console, you’ll never receive such valuable notifications. And, by the way, that’s not the only security problem that Google will be notifying you about.

2. If you receive “new owner” notifications from Google, don’t take them lightly. Not only should you unverify all unknown accounts, but also investigate how they were able to verify them. In most cases it means that they had full access to your site, so you should close all the security holes and remove any malicious content that the hackers might have already created on your site.

3. As I demonstrated above, it’s quite easy for hackers to remove you as an owner of your site when someone has access to your server. And you will not even be notified about this. If you don’t want hackers to be able to easily unverify your account, consider the following 3 alternative verification methods:

Via a domain name provider;

Via a Google Analytics tracking code;

Via a Google Tag Manager container snippet.

Unlike the HTML file and the Meta tag verification methods, these three require hackers to have access to your Google and domain name registrar accounts in order to be able to unverify you.

To Google

Although Google does a great job quickly notifying site owners about potentially malicious new owner verifications and providing them with all the information and tools needed to troubleshoot such issues, it looks like they are not prepared for some scenarios.

Why not send a “goodbye” notification to a recently unverified site owner? Even if it was a completely benign unverification of someone who no longer works on the site, these people deserve to be notified about it. Since they are no longer “site owners” there should be no concern that Google is sending too many notifications. On the other hand, if the unverification was malicious, the real site owner will definitely want to know about it!

We see that hackers sometimes verify quite a few accounts in a very short time. It’s good that you send notifications about each of them. Maybe you should also consider such an activity as a sign of compromise? That’s a good reason to take a closer look at a site (I mean your malware and spam scanners) and flag the added accounts for some additional investigation, especially when they appear on many unrelated sites (hackers likely reuse accounts when they break into thousands of sites and verify dozens of accounts for each of them).