Question

In a refund tech scam, tech scammers use Chrome Developer Tools to edit the HTML directly on the victim's bank webpage through a Remote Desktop (Teamviewer, AnyDesk, etc) to fool their victim into thinking that they received a 'refund'.

I was wondering if we could detect if the innerHTML of the victim's bank balance has changed (some DOM event?) and compare the value to a private variable storing the bank balance, reload the page if a mismatch was found. A timer could also be used. Is there any way the scammer may be able to stop the listener/timer code from running without being detected by the Javascript code?

Although this may be a stupid idea, making these scams harder to execute for scammers will definitely slow down their progress on scamming more vulnerable victims.

Was it helpful?

Solution

If you have seen videos of this being done, you will realise how crude the attack is. The attacker literally types in values in real time while talking to the victim.

So I although, yes they could defeat any check you made. Could they defeat it in real time? Probably not.

And it would be fairly easy to implement a check sum, or use images for critical sections etc to make manual editing of the page untenable.

This would force the attacker to develop an automated solution, which considerably increases the difficulty of the attack

OTHER TIPS

There are some golden rules in Information Security that say that:

  • If an attacker has physical access to your device, it's no longer your device.
  • If an attacker has administrative access to your device, it's no longer your device.

Remote access via TeamViewer etc. is not exactly "physical access", but it is a high degree of access. Plus, most users are logged in as some kind of "power user" or "local administrator" anyway, so rule #2 applies.

In other words: the problem is not the editing of the DOM, it's the fact that the attacker already has gained access to your system.

As pointed out in Telastyn's answer, it is a simple matter of logic that, if an attacker can edit the DOM to insert elements, they can just as easily edit the DOM to remove the checks you are talking about.

The only way you could detect the DOM change is client side. Since it’s client side, attackers could simply delete that check.

So yes, it could add a tiny hurdle to the least capable of attackers; probably not worth the added effort and complexity.

Where are you doing this proposed check? Clientside or serverside? Either is flawed:

If clientside, then not only can a local attacker figure out the validation logic to get around it - what makes you even trust the clientside validation if an attacker has already proven to be capable of editing the page?

If serverside, then not only are you going to have to send your entire HTML back, but what's stopping the attacker from making a webpage that looks different to the user than what it sends back to your server?

In either case, when you get to the part of local attacker access, you're at a dead end.

Licensed under: CC-BY-SA with attribution
scroll top