Coming from this comment from this question at Travel StackExchange.

My question is: How can the scammer still scan a user's data when the user registers their account on the legitimate site, after being redirected from the fake site?

So, suppose I go to homeaway-eu.com. I'm then redirected to homeaway.com. Now I search for a house and book it, after entering my data. How can the scammer get this information that I entered, such as my payment details and contact infos?

Edit: I think the answers below are coming from the point of view of the question that I linked above. My question is about the supposition that I wrote, not the exact case from Travel StackExchange.

  • I'm not sure to understand... It's impossible for a website to retrieve infomation that is not on it. So if you're just redirected from homeaway-eu.com to homeaway.com wihtout typing any credentials, unless if it exploits something to install a virus, the attacker can not see what you're doing on other sites.
    – Pierre G.
    Jun 3, 2019 at 12:13
  • @PierreG. yes that was my question, sorry if it was confusing before the edit.
    – Snow
    Jun 3, 2019 at 12:16

3 Answers 3


If I understand that comment and question correctly, the scenario is:

  • There is a legitimate domain, homeaway.com
  • There is a site registered by a presumably malicious party, homeaway-eu.com
  • At the time of the question, homeaway-eu was simply a redirect to homeaway.com
  • You are asking specifically about how opening a browser and going to "homeaway-eu.com" could help an attacker, considering that in doing so, you immediately end up at the legitimate homeaway.com.

You are correct that any information you enter on the legitimate howeaway.com should not be accessible to an attacker. Having a redirect to the legitimate site does not allow any shenigans on data entered on the legitimate site. However:

  • If in the future an attacker Eve sets up a data entry form on homeaway-eu.com, when then submits the data to homeaway.com, she can collect the data. Since the evil domain submits to the real domain a user might not even notice, especially if the user is accustomed to going to homeaway-eu.com instead of the real site.
  • As the comment you linked points out, Eve could start sending mail as eve@homeaway-eu.com. A user might not be suspicious since going to howeaway-eu.com goes to the expected site. There is no address spoofing involved so this will basically be impossible to detect. As far as email providers are concerned, Eve has a legitimate domain which she owns, it just happens to be similar (to humans) to a completely different domain. This can aid in social engineering and phishing.
  • If Eve knows about an exploitable brower bug, she could easily set up a "drive by" attack on a user who visits her site, prior to redirecting to the real site. The user would be none the wiser as they end up on the correct site.
  • If Eve is only collecting IP addresses for future attacks (or subpoenas, if Eve is working for a government agency, and it turns out the "legitimate" website is questionable itself) then the redirect webpage is all she really needs to accomplish this task, with no further action required.
  • Perhaps the redirect site reacts to specific IP addresses or ranges, or perhaps it looks for specific tracking cookies, and does something different based on that.

There is probably more I missed. In general, going to an attacker-owned webpage is not a good idea no matter how benign it may appear.

  • 1
    This is exactly what I was looking for, thanks! I thought there was an attack that could be done after the redirection, which involved stealing the data that the user enters on the real website. Glad that wasn't the case.
    – Snow
    Jun 3, 2019 at 12:28
  • 1
    Thanks for also pointing out the other kinds of exploits that the attacker could use!
    – Snow
    Jun 3, 2019 at 12:28

The process is simple. For the sake of demonstration, let's use the domains legit.com and evil.com. In a real-life scenario, you would probably see something more like legit.com and 1egit.com.

  1. The Scammer sets up the domain evil.com and mirrors the design of legit.com
  2. The Scammer then directs potential victims to their site.
  3. The Victim registers a new account at evil.com
  4. The Scammer now has the login credentials of the victim and registers a new account in the name of the Victim with their credentials.
  5. The Scammer then redirects the victim to legit.com.
  6. The Victim receives an email regarding their registration at legit.com. To the Victim, this seems perfectly fine.
  7. The Victim now enters payment details to purchase something from legit.com
  8. The Scammer, who has access to the Victim's account, will see that a new purchase has been made and can grab the payment information from the victim, if legit.com exposes it.
  9. (Optional) If legit.com does not expose payment information, the Scammer can contact customer service, claiming to be the Victim and asking for assistance. The Scammer can claim they don't know which credit card was used to make the purchase, and customer support is instructed to help customers, not to protect their data at all cost.
  • But as per my supposition, the user is redirected to legit.com when opening evil.com. So at step 3, the URL is legit.com, or in my example: [1]: homeaway.com
    – Snow
    Jun 3, 2019 at 12:04

When you complete a form on the Internet, the browser sent what is called a POST request, meant to send information to a server. The POST request is made to a specific script on the server and the URL of the script is embedded right in the HTML code.

So, if an attacker make a copy of a website, he can change the HTML to tell the browser to send information not to the legit server, but to his server.

With that, the attacker now have your information such as credentials and can redirect you to the legit website, log you, and it will seem like everything was just fine.

This is why you should always be checking the URL you're on, even if it's HTTPS.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.