I agree with Kotzu, I would have commented, but just for being able to post a screenshot, I am posting this as answer.
Yes, Host Header Attacks are possible on IIS and ASP.NET stack.
Password Reset Poisoning:
This happens if code is written poorly, on website when user requests a link to reset password, the website sends out a link with secret token to that user's email address.
Say that link is http(s)://[genuinesite]/resetpassword.aspx?someguid
And guid would be a key to a record in database which knows for whom to reset the password.
But if code was written poorly to create that link, it would use Protocol + Host Header + "/resetpassword.aspx?" + guid,
then attacker can easily pass host header to his own website,
So the genuinesite will generate and send email with link like http(s)://[jenuinesite]/resetpassword.aspx?someguid
and the attacker would have that site there,
and he would be able to get the query string parameters and be able to reset password on behalf of the user, provided that the user actually clicks the link from email. And usually they do because email is really sent by genuinesite.
Many popular software components have this vulnerability.
Cache can be poisoned by HTTP Response Splinting too which is again not common now a days, but here we are talking about Host Header.
Caches are now a days host-aware, so with Host Header if someone tries to poisons the cache, it will be kept separate from the genuinesite's cache.
Say the code is generating html like Home then by manipulating host header you can make it like Home
And that page would be cached server side, and the attacker can steal cookies of all the users whom that cached page gets served.
Obviously, the attacker will use Pragma: no-cache to remove the genuinely cached page first and then position the cache with host header manipulated version.
But like I said, in ASP.NET and IIS world I haven't seen Cache Poisoning with Host Header much, but we never know people write poor code all the time.
How do we prevent this:
I think the easiest way (and one of the best practice) is to have proper binding settings in your IIS, even if you are hosting only one website with your IIS.
You can even have multiple allowed host names for one web site.
This way, if someone changes the host header, it will not even reach your web site in IIS.