1

How would one go about defending against this sort of attack to best protect a sloppy user? There can be obvious signs of a spoofing attack, such as not using SSL, slightly different domain, etc, but I am assuming Tristed.com (the malicious site) has completely fooled the user. The only mitigation that comes to mind is having automation prevention built in, like Captcha. I don't know if I am completely missing something here, so apologies in advance. I have abstracted a lot of detail for the sake of keeping the diagram simple.

Multi-layered attack

-1

What you are describing is basically a user that enters his credentials on a malicious site that appears to be a trusted site. Those credentials are used afterwards to compromise the account of the user.

You are totally out of the loop until the credentials are misused, so there is no direct technical measure you can set. Even the CAPTCHA you proposed to protect against automated misuse afterwards does not work, because this CAPTCHA can be forwarded to the tricked user as well.

This means your best approach is educating your users, how to identify malicious sites. One good measure to suggest is bookmarking the site instead of searching for it. This would eliminate future mistakes, as long as the bookmark is used.

In addition, you can monitor to identify fraud scenarios and react fast to mitigate damage. In case the attacker is sloppy and uses a single IP address to access the real site, you can detect many different users coming from the same IP, which might be an indicator of such an attack. Please note that a larger network behind a NAT would look the same, so be careful with countermeasures.

If you have control over the user environment (e.g. they are clients on your corporate network), you can enforce client side protection mechanisms. I assume you are talking about outside users though, because they use a search engine to find the site, so I won't go into details concerning client side measures.

| improve this answer | |
  • Thank you for the answer. Before I accept it, I would like to get your opinion on how effective 2FA would be in deterring this type of attack. It just came to me that 2FA might be the only direct mitigation for this scenario, and in addition, all of the prevention strategies you mentioned in your answer. – spencer741 Mar 7 at 17:52
  • 1
    Unfortunately 2FA does not work in this scenario as well, because Tristed.com can interact in real time with Trusted.com. So if Trusted.com requires a second factor, Tristed.com will see this during the login process and asks the user to provide this information as well. Whatever Trusted.com is asking can be fetched by Tristed.com and passed on to the user. – Demento Mar 7 at 18:06
0

A good security measure for this is having a navigation proxy in place that block suspicious websites.

In this case maybe tristed.com have been created recently or is unclassified or directly suspicious and a navigation proxy may block or alert against it.

Similarly may be a DNS solution may find the URL suspicious and block it by resolving to a sinkhole IP.

| improve this answer | |
  • In the case that the generic http client (from tristed.com) would first route requests through a trusted proxy before hitting trusted.com, would there be any additional methods for prevention? – spencer741 Mar 7 at 17:20
0

You can use webauthn in order to get different responses to a challenge from tristed.com, which could not be used on trusted.com.

This is however linked to a specific device or OS account. You thus need the user to either have a compatible hardware component, or have them be able to only use the account on linked OS accounts (though I have only used the hardware device so don't know how easy to use the system is without one).

| improve this answer | |

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.