Anatomy of a Redirect Attack

Details on a redirect attack to this Web site


Like any Internet facing web site, this site is regularly probed by hackers for any known weaknesses they can exploit. Based on my daily review of the web server log files, most of these probes consist of attempts to request resources that either have known exploits or can provide information that can be used to compromise the web site's security or integrity. These resources are typically either part of a software application, or administrative/test files that shouldn't be deployed to a production web site. These probes are unfortunately a normal part of doing business or providing information on the Internet. While the probes are frequent, most attempts are usually not successful. This site was recently the target of a successful malicious redirect attack. Because I felt that others might find it interesting, I decided to write up what I have learned about the attack. To the best of my knowledge, no personal or private information was compromised in this redirect attack.

What is a Redirect Attack

So what is a redirect attack? That is when code is inserted into a web site with the intent of redirecting a visitor to another website. This is done to fool a user into trusting a malicious or lower reputation page by making them believe it is from a trusted or higher reputation source. There are several ways to implement this type of attack. I will not go into detail on all of them in this article. In this specific instance the attacker accomplished the redirect by inserting a new file into the web site and pointing search engines directly to the new file. None of the rest of this web site was changed or affected, making the change less obvious. The only time the redirect took place was if a user directly requested the URL of the newly inserted file. The only way to find the inserted file was through a search engine.

How I Was Notified

The way I learned that this web site was compromised was indirectly through the Google Search Console. For those not familiar with this Google tool, it is a tool that webmasters can use to help measure and optimize a web site's search traffic and performance. The web site owner or webmaster registers their web site with the tool by providing proof of ownership for that site. This proof can come in several forms. Google will send a verification code that is then placed in either a DNS TXT record for that domain or in a file in the root of the web site. Once the site is registered the webmaster can submit a sitemap that describes the layout of the web site. This sitemap provides information that Google can use to more efficiently index the web site.The search console can then provide performance information as well as identify usability issues.

I received an email from the Google Search Console that a new owner had been added for this site. Google routinely sends an email to notify all site owners when site ownership changes. I knew I hadn't added any new owners as I am the sole owner for the site in Google Search Console. By checking the email headers of the notification email I was able to confirm that the email was legitimately from Google. I immediately logged into the search console and checked the web site owners listed there. I was the only owner listed. I was going to attribute the email I received to a software error, but wasn't comfortable with doing that just yet. 

Further research revealed that there was a way to use another Google tool called Webmaster Central that can list in detail any verification requests to become site owner for search console. Webmaster Central did indeed show a successful verification attempt and the addition of a new site owner in the search console. While I had verified myself using a DNS TXT record, the malicious owner had verified themselves using the file method of verification. In order to successfully verify themselves using this method, they would require access to the root directory on this web site. If so, the web site had been compromised.

Initial Clean Up

A quick check of the root folder on this web site revealed the verification file the malicious hacker had placed there. I immediately deleted the new owner in search console and the verification file on this web site. With that cleaned up, I began the investigation into how the attacker had gained access to the site and what they were attempting to accomplish.

At this point I need to make it clear that while I was notified by the Google Search Console, it was this web site that was compromised and not the Google tool. Once the web site was compromised the attacker was able to authenticate themselves with the Google tool. It was actually the security built into the search console that made me aware that the site had been compromised.

Once the newly added owner and verification file had been removed I started digging into what malicious activity the hacker had been performing. My first stop was the web server log files. The files always have plenty of unsuccessful attempts at retrieving non-existent URLs. This time I noticed a URL I didn't recognize being requested successfully. The resource being requested was inidwf.aspx. The HTTP referrer for these requests was from, a Chinese search engine that was indexing the site through this aspx page. A quick check of the root folder of this web site turned up the inidwf.aspx file. More evidence that the site was compromised. In a panic, I quickly deleted the file. If I had been thinking more clearly I should have saved the file so I could analyze it further. At this point I changed my web hosting password in case it had also been compromised. I then notified the ISP hosting my web site so they could determine if it was just my account or a much larger breech.

Research and Discovery

Now that I could breathe a little easier I had the urge to dig a little deeper into what the intruder was actually attempting to do on my site. Since I had hastily deleted the evidence I couldn't just look at the aspx page code to see what it did. I also wanted to determine exactly why they needed site ownership in Google Search Console. I had initially assumed (incorrectly) that they wanted access to the search console so they could monitor the performance of their inidwf.aspx page. More on this later. And I still needed to determine how they had gained access to the file system on my hosted web site.

My first step in this analysis was to ensure that I wasn't somehow deploying these extra files from my development environment. A quick check of the folder I deploy the web site from revealed that it was clean. Then I checked the sitemap file I deploy with the application for any references to inidwf.aspx. It was clean as well. That led me to check the sitemap in the search console to ensure it was the same as what I deployed. That's when I noticed there were now two sitemaps for my web site in search console. The first sitemap was the one that I deploy along with this web site. The second sitemap pointed to inidwf.aspx with a number of URL parameters that I assume directed the aspx page to return a sitemap for Google to index. According to Google, it had indexed 1800 entries for this sitemap. I hastily deleted the extraneous sitemap. Once again, I should have retained a copy for analysis.

This sitemap got me wondering what site was being indexed as a part of my site. A quick Google search for inidwf.aspx turned up a number of sites.  I reviewed several of the the sites returned from my search. All of them were legitimate eCommerce sites, except for the fact that they had this extraneous aspx page. All of the search results referenced the inidwf.aspx page on the legitimate site and passed in parameters with id numbers and the compromised site's domain name. The offending page redirected to the eCommerce site This eCommerce site has a very low reputation, so the attacker was using legitimate sites with higher reputations to redirect traffic to their site. This explained why they needed access to Google Search Console (to have their bogus sitemap indexed) and the reason for inserting inidwf.aspx on to my web site (to provide the bogus sitemap and redirect to their shady eCommerce web site).

Outstanding Items

I'm still not certain as to how the hacker gained direct folder access to my web site. One possibility is that my password has been compromised. If so, changing it and enabling two factor authentication should help mitigate that issue. Since the attack is wide spread rather than isolated to this web site it is possible that the attacker is using an exploit that is common among all of the affected servers. The Web hosting provider for this site is researching log files across their hosted domains to help determine how the intruder gained access. They have notified me that they have deleted the injected files and are synchronizing permissions. I don't yet have a clear answer as to how the intruder gained direct folder access to my web site.

Written by KB3HHA on 07/09/2021