[BillDemirkapi]

Author here. Yes simply editing my hosts file would have been much easier. The reason I went the longer approach of setting up the payload on a remote web server was because there is the concept of security zones in Internet Explorer. Visiting localhost in Internet Explorer gets treated with a different level of trust compared to randomwebsite.com. For example, if you go to your security settings in Internet Explorer, there is an "Internet" zone but also a "Local intranet" zone. If you compare the two, you'll see they have different security settings. By hosting the payload on an external domain, we ensure that we are simulating an identical environment that existed for the attack (and are not subject to a different level of trust).

[EvanAnderson]

Editing the HOSTS file has nothing to do with where the resource is hosted. It just allows you to control name resolution without doing it in DNS. Internet Explorer security zones work the same way irrespective of whether a local HOSTS file for DNS resolves the name.

[BillDemirkapi]

Yes, but at the time I already had an existing domain with a web server I could use. You are correct that I could have setup a separate site for hidusi[.]com and then point the domain directly at my web server's IP, but since I already had a domain/web server configured, it was much easier just to swap the domain in the document.

[kjaftaedi]

Your comments give me the impression this isn't totally clicking just yet.

All that is necessary is to add an entry in your hosts file for hidusi[.]com that points to the IP of your existing server.

That's it. Step completed.

No localhost, no new site, just using what you have already.

In the event you are filtering hostnames on your web server, you would just add hidusi[.]com as another alias.

Please let me know if this is not clear because I believe understanding this concept will help you in the future.

[BillDemirkapi]

I can assure you the answer clicked before my research ever started. Unless I am using web server software that responds with one site for multiple host names, you generally need to configure each host name that might be used with your web server as a different "site" (i.e Apache) / configuration. I could have simply edited my hosts file with hidusi[.]com pointing to my web server and created a separate site configuration to serve the hidusi[.]com domain with the second stage. What I was saying in my last response was that instead of using my hosts and having to create this new site configuration (or modify existing with an alias), I could just swap out the domain in the document and use my web server's current state without any additional modification required. It was simply more convenient to change a single domain rather than update my web server's configuration to support requests for the hidusi[.]com alias. There is no significance to using the original domain for serving the second stage, I think you all are all just overthinking it :)

[kjaftaedi]

All web servers respond to all hostnames. It is the default unless you have configured it otherwise.

In the event you are doing virtual hosts in Apache, you just add a single line:

ServerAlias www.example.com

And your webserver will respond when queried via this hostname.

So, even in the worst case scenario, we are talking about two very basic lines of text to accomplish your goal.

The whole setup should take about 60 seconds.

I am not trying to say that your approach is wrong, but just that there is a much simpler way to go about accomplishing this goal.

As far as "overthinking it".. I think we are going to have to disagree here because I am unable to see how your method of reverse engineering can possibly be simpler than something that takes practically no time or effort.

At any rate, this is not an argument, I just want you to be aware of your options as you continue your research.

I wish you luck as you continue exploring, and thanks for the writeup :)