As others have mentioned this is likely one of a couple of scenarios, roughly ordered by my guess on likelihood:
- Attempting to use your legitimate content and services to improve the SEO rank of other domains (even unrelated ones). This can usually be checked by looking for a sitemap.xml, there will be pages not redirected to your site that contain pages of links.
- Closely following the above, the pages may not be links to other sites but might be hosting phishing pages for other services unrelated to yours. The redirect here acts as a bluff for casual inspection of the domain. You won't see page entries in a sitemap.xml file for these ones.
- Attempting to "age" a domain. Not many talk about this option, but new domains are a red flag to a lot of automated security processes. When purchasing a domain and giving it a history associated with a legitimate service they make the domain look less suspicious for future malicious use.
- Preparation for a targeted campaign. This is pretty unlikely, you need to be really worth a dedicated long term campaign effort specifically against you or your company. If you're doing controversial/novel research, are managing millions of dollars, performing a service a state actor would object to, or have high profile clientele then maybe you fall into this category. These are patient campaigns and want to make the domain "feel normal and official". They won't do anything public with the domain such as SEO tweaking or link spam, they'll use these domains only for specific targeted one-off low-noise attacks. They're relying on staff to see that the domain has been connected to your service for years and is likely just a domain someone in marketing purchased and forgot about. This is exceptionally rare.
Regarding point two, OP should connect to a VPN in Japan or somewhere he very isn't, use incognito mode, and see if the same content is served. I've seen hacked sites that are set up to serve normal content to where the attacker thinks the owner of the site lives, but serve phishing content or malware or whatever to everywhere else.
A 301 fits that bill because then the owners browser even when traveling will serve the good content
Can you get Google Safe Search to do that? I feel like my reports fall on deaf ears because SMS spammer's URLs would only serve 'bad' pages to $MyCountry (and nowadays do it behind a captcha, fuck you hcaptcha).
I have seen attacks where directly visiting the site doesn't show anything out of the ordinary, but visits coming from Google (referer) show different content. Have also seen ones where only User-Agent: Googlebot would see the modified version of the site.
(I doubt that is the case in OP's situation, but I have seen both of those methods of "hiding" multiple times now)
Yes, this is how most Wordpress malware works - they inject/publish ad or keyword spam content on the site if the user agent is googlebot. Regular users don't get the ads. It's partially why most people never realise their site has been hacked.
Or, try a mobile user-agent. I've seen loads of phishing pages that will only serve their malicious payloads to phones - this is especially common with the scams that are sent via SMS.
Yeah this is a good call-out. If the site is being used for drive-by or targeted malware there are other checks that may be happening alongside the redirect such as user agent, country of origin (like you mentioned), plugins installed, OS, or even time of day.
If they detect something that matches what they want, they may throw some intermediate 301's to pages that attempt to infect the user with something still ultimately redirecting to the "normal" page.
Just a note 301s are super sticky and browsers cache them even across incognito modes. Your best bet is to use a new browser after reconnecting to avoid false results.
On Chromium-based browsers, if you open the Developer Tools (F12 or Inspect in right click) and you go to the Network tab, you can click 'Disable Cache'.
In my experience, this solves the sticky 301 issue and you should have no issues with cached 301s anymore.
Works perfect for these kind of investigations or if you made a mistake during site development.
I'm not GP but a decade ago when I started out as a web developer I made the mistake of using 301s in production and at the time we never figured out how to get the browser to re-learn the responses for those pages without drastic measures.
I still never use 301s for that reason. Things may have changed, but I dare not try!
> I still never use 301s for that reason. Things may have changed, but I dare not try!
I use 301 for http:->https: redirects because (a) I doubt we're going back, (b) it prevents some cleartext leaks (like the Host header), and (c) it is slightly cheaper.
> we never figured out how to get the browser to re-learn the responses for those pages without drastic measures.
If you control the target URL it is easy, just redirect back. Seriously: The browser won't loop, it'll just fetch the content again and now not seeing a 301 will forget that nonsense ever happened. This is why 301 is usually a fine default for same-site redirects, or if the redirect target is encoded in the URL (such as in tracking URLs).
The big no-no is don't 301 to a URL you can't control unless you have the appropriate Cache-Control headers on the redirect.
Yeah that's a good point, but one way to think about a CDN is like a web browser that you control, so I say do it even with a CDN and remember you can always just flush the "browser" cache! (or in cloudfront's case: create an invalidation and wait a few seconds)
You can disable caching in Firefox's developer tools, this covers such cached redirects. Very useful combined with a persistent log of network activity to avoid clears after redirects.
There's a related site compromise where a hacked webserver behaves normally except, when the referrer is google.com, it adds a JavaScript redirect to the end of any page.
You go to example.com, everything looks normal. You click a link to example.com, you end up on a page selling herbal dick pills. Site owner yells at Google thinking it's their fault. Googlebot never gets served the redirect.
You should be able to do the same thing with 301 redirects.
OP, you can search for "site:getexample.com" which will list you any pages that have been indexed for that domain. They might have just redirected the homepage. Worth a shot.
It could be a combo of 1 and 3: a competitor (or someone who thinks they might be in the future) ages those domains, then points it to their own product later.
This is another great call-out and semi-common. I can definitely get blinded by my security focus but shady business tactics drive a lot of these similar domain purchases for exactly the reason you described.
Bait and switch? Get users t bookmark the joinexample.com, and the others, and once they notice that people keep going to your side via their domain names, they will switch, make a fake "change password" and will be ripped off.
Just speculating here, but would it be possible that the redirecting domains could actually overtake the original site in terms of search rank, etc? If yes, this could be preparation for a semi-targeted phishing campaign:
1) set up plausibly-named fake domains that redirect to example.com
2) ensure that the fake domains rank higher than the original domain for "example" searches.
3) after a while, people have gotten used to accessing the service through the fake domains or might even think those are the official domains.
4) pull up the net by replacing the redirect with phishing pages. Suddenly, everyone googling for the service will end up on a phishing site, without any obvious way to fix the situation.
Phishers could also run this scheme for lots of sites in parallel, without needing to have some specific interest in any of them.
Edit: Seems like the semantics of the 301 redirect should prevent this from working though.
one another scenario is that if you open the domain from browser, they will do 301 redirect, but for traffic coming from Google/search engine, they will show their actual content.
I'd add canonical link elements to your html and http headers in order to reduce the chances of subversion somehow. The whole thing feels really weird to me.
I'll add another scenario I've personally experienced:
- Reaching out in good-faith with an offer to sell the domain to you. I've had that happen in the past and before receiving the email the person directed the domain to my official website to show good will. I purchased the domain and now own it.
Not saying this is the case here, but just wanted to throw a legitimate scenario into the mix. They should have reached out by now if this was the case.
- Attempting to use your legitimate content and services to improve the SEO rank of other domains (even unrelated ones). This can usually be checked by looking for a sitemap.xml, there will be pages not redirected to your site that contain pages of links.
- Closely following the above, the pages may not be links to other sites but might be hosting phishing pages for other services unrelated to yours. The redirect here acts as a bluff for casual inspection of the domain. You won't see page entries in a sitemap.xml file for these ones.
- Attempting to "age" a domain. Not many talk about this option, but new domains are a red flag to a lot of automated security processes. When purchasing a domain and giving it a history associated with a legitimate service they make the domain look less suspicious for future malicious use.
- Preparation for a targeted campaign. This is pretty unlikely, you need to be really worth a dedicated long term campaign effort specifically against you or your company. If you're doing controversial/novel research, are managing millions of dollars, performing a service a state actor would object to, or have high profile clientele then maybe you fall into this category. These are patient campaigns and want to make the domain "feel normal and official". They won't do anything public with the domain such as SEO tweaking or link spam, they'll use these domains only for specific targeted one-off low-noise attacks. They're relying on staff to see that the domain has been connected to your service for years and is likely just a domain someone in marketing purchased and forgot about. This is exceptionally rare.