Forensic Analysis of: Quick Assist

Social-engineers are relentless, audacious and sometimes... Well, genius. On paper, what chance does a determined intruder have of getting an unknown individual on the other end of a phone or email to: Firstly download a piece of unknown software and install it, secondly grant them permission to control the computer, then finally go for a coffee break. Unfortunately, not as small a chance as you would think. I for one have seen this in both a personal and professional context.

Five years ago, I remember coming home from work to find the family computer (my gaming rig) unplugged at the wall and phone ringing, a social-engineer on the other end who had achieved partial pwnage but had then suddenly lost connection. My partner had been home when someone from the 'telcoms company' had called to rectify 'a problem with our home internet' that could only be resolved manually... On the desktop itself... Well, it so happened that we were indeed customers of the stated ISP, so it wasn't until the cursor started 'moving by itself' that my spouse's osmosis-absorbed IR training kicked in. Fortunately, the PC survived the 'pull of the chord' and with no new additions courtesy of our mystery caller.

Responding to an intrusion of a customer's network as part of a Managed Security Service Provider (MSSP) CSIRT in 2022, these memories came flooding back in a situation whereby the attacker had successfully achieved remote access through the use of third-party screen viewing software. In this investigation, the software stood out instantly as being abnormal purely because it wasn't routinely used anywhere else by the organisation.

But how much longer would it have taken to identify the patient-zero host if the attackers had used Quick Assist? As you'll already know, 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
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