Embedded Files
Quick Assist was introduced in Windows 10 and comes pre-installed on the Operating System, which is not only a gift social-engineers, but removes 'download and install' Indicators Of Compromise (IOCs) for Incident Responders as well. As you'll also know, Quick Assist has been a concern to security researchers since its release for the following reasons:
You don't need administrative privileges to run it and establish a connection with an external user (which can be anyone with a Microsoft account).
It uses a Microsoft domain on port 443 so is unlikely to be blocked on firewalls.
It can't be centrally managed with Group Policy making disabling or uninstalling it difficult at scale.
These concerns encouraged me to take a close look at the application to identify what it looks like both on the host and on the network.
Screenshot of 'attacker' controlling 'victim' machine
Here is what I found
Quick Assist uses Microsoft’s infrastructure to broker communications between the user ‘Giving Assistance’ (our attacker) and the user ‘Getting Assistance’ (our victim). This means the attacker’s IP address is never exposed to the victim, nor is the attacker’s Microsoft account email address. The only clue at the attacker’s identify comes from the account name provided in final prompt given to our victim prior to granting access, which could easily be named to coincide with the attacker’s pretext.
Screenshot of victim ‘Share your screen’ pop-up
Whilst the application uses Microsoft infrastructure, the domains used for communications can be used by defenders for firewall rules and alerts. During our experiment we observed DNS requests for the following domains which could be used as an indicator that a Quick Assist screen share had been established:
From the victim’s side:
relayv2.support.services.microsoft.com
…which pointed to the CNAME:
rdprelaytrafficprod.trafficmanager.net
…which pointed to the CNAME:
rdprelaynortheuropeprd.cloudapp.net (presumed regional)
…which resolved to a Microsoft-owned IP.
From the attacker’s side:
rdprelayv2northeuropeprod-2.support.services.microsoft.com (presumed regional)
…which pointed to the CNAME:
rdprelaypublicip.2.rdprelaynortheuropeprd.cloudapp.net (presumed regional)
…which resolved to a different Microsoft-owned IP observed in the vast majority of Quick Assist network traffic.
All ‘rdp’ traffic on both victim and attacker sides used HTTPS on TCP port 443.
As the domain suggests, the Quick Assist process uses Remote Desktop Protocol (RDP) libraries, and on the attacker’s machine RDP bitmap cache files could be found that revealed snippets of the victim’s shared screen with the prominent yellow border visible in Quick Assist.
Screenshot of RDP bitmap cache snippets
Conclusion
This technique of gaining access to a computer is often associated with ‘vishing’ and is arguably more prevalent in the home environment. However, it has been observed in enterprise environments and Quick Assist offers skilled social-engineers an opportunity to bypass firewalls with what is often implicitly trusted Microsoft infrastructure. It also removes the need for victim’s to install a non-native application their system and a lack of application and security logging could hamper incident response procedures.
Quick Assist is built on trust of the user ‘Giving Assistance’, and credit to Microsoft, it is an incredibly useful tool which enables Windows-savvy people to resolve the IT issues of family members or colleagues both directly and remotely. However, as with everything in IT, trust can be (and often is) misplaced, and can be (and often is) abused.
Research conducted in January 2022
Page updated
Google Sites
Report abuse