I asked this on the Twitter thread and got no response. Is this even useful on its own? Or at all? It requires a redirect to some other domain where the VNC is hosted.
Would modern up-to-date browsers just see it as cross site and block it?
Wouldn't it still require sneaking in the VNC code to the site you want that user coming through via a pre-existing exploit chain or social engineering scheme?
By itself this seems negated by standard browser security. If youre using it at the end of some exploit chain it seems like there would be several other more effective and useful things to do from that chain like an invisible proxy mitm.
There are two browsers involved, both dealing with just one site and neither in any way aware of the other.
The outer browser is running on the user's machine, loading a page from the attacker's origin. That page makes no cross-site requests, but just establishes a websocket connection to the attacker's server (the data connection for the remote desktop protocol) and renders the remote desktop to the outer browser on a canvas.
The inner browser is running on the attacker's server, just configured to show no URL bar or other chrome. It has loaded the genuine login page of the target site completely normally.
It's your site, so you can set the URL to anything you can buy. In the demo he is using an IP, but nothing to stop you buying gooogle.com or something with Unicode tomfoolery that will be enough to pass muster for most victims and look authentic at first pass.
Would modern up-to-date browsers just see it as cross site and block it?
Wouldn't it still require sneaking in the VNC code to the site you want that user coming through via a pre-existing exploit chain or social engineering scheme?
By itself this seems negated by standard browser security. If youre using it at the end of some exploit chain it seems like there would be several other more effective and useful things to do from that chain like an invisible proxy mitm.