You're asking the wrong question
Remember that UAC helps protect against malicious code by giving a user with administrative rights the option to deny a (potentially malicious) process from starting execution on the local machine.
That said, in simple terms, your example scenario describes malware on a computer leveraging RDP to bypass UAC and launch an attack against the local computer. For this attack to work, the malware must already be running on the computer, rendering efforts to bypass UAC entirely pointless.
Therefore the correct question to ask is how the malicious process was able to bypass UAC on Computer A in the first place.
What about Computer B?
While not the direct query of your post, your scenario could work in an attack against Computer B. Allowing that Computer A is already compromised, it's possible a malicious program could start an RDP session and send mouse movements or keystrokes to Computer B, including those necessary to bypass UAC.
But neither is this a legitimate security vulnerability.
First off, the following is not default behavior in Windows:
I can use RDP (remote desktop) to connect to computer B from computer A without typing my password.
This is only possible if you have either:
- Saved credentials for the remote computer (which are then stored in Credentials Manager), or
- The Allow Delegating Default Credentials group policy has been configured.
Neither of these are present in a default configuration. I'll refer to both of these as having "saved your credentials."
Therefore, the RDP connection to Computer B by the malware is only possible if you've saved your credentials on Computer A. Since any code running in the context of your account on Computer A can access saved the credentials, the act of saving them is the equivalent of declaring, "I explicitly trust any current or future code executing in the context of my user account, including malware."
By saving Computer B's access credentials on Computer A, you disable the access control mechanism meant to control access to Computer B (from Computer A, at least). Code that leverages this fact isn't exploiting a OS-level vulnerability, but rather a user-created one.
First of, the malware has to be run, then it has to actually know a computer that it can RDP into, then it has to know how to RDP back. These situations are so unlikely to encounter, that the chances are slim to none that malware will utilize this. You cannot RDP to yourself so its more likely that there will not be a situation exploitable by generic malware to do this. – LPChip – 2018-03-20T18:36:27.833
Also, the only reason you can remote into another computer, is because you once entered your username and password, and hit save credentials, and when you RDP into a remote computer, the host is locked out, so a loopback as you suggested is not even possible. – LPChip – 2018-03-20T18:37:13.713
@LPChip It is possible to RDP to
localhost
on 1) Computers that support multiple simultaneous RDP sessions (e.g. Server editions), and 2) If theRestrict each user to a single session
policy is set to "No". Even if that policy is set to Yes, it's still possible as long as you use a different user account, which would be feasible for a user with admin rights on the remote machine, as the OP obviously has since the remote UAC buttons are Yes/No. – I say Reinstate Monica – 2018-03-20T20:03:06.743