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.


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

  • A checksum or hash of the DOM, to be compared against the server, would be the only things I could think of too, with the AJAX call being obsfuscated and tucked away somewhere where the scammers wouldn't notice it. The other answers mentioning how any sort of check is pointless are missing the fact that this scam is probably not targeted at one specific bank, so even slowing down the scammers a tiny bit might work, as they will focus on easier targets. – Graham May 28 '20 at 13:39
  • I probably didn't explain the context clearly, but you're right. These scammers want to perform these refund scams on as many victims as they can. The scammers usually follow a script and they are not an expert in client-side hacking as hiring computer experts costs money. Even by doing a few client-side checks, it will defeat many of these call centers that do brainless 'inspect element' edits infront of the their victims. – Joseph Goh May 29 '20 at 10:48

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.

  • Also, if they have admin access, they can also quickly set up a man-in-the-middle cert and DNS and would not have to tinker with the browser at all... (except maybe for resetting certificate pinning) – marstato May 28 '20 at 9:56

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.

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.