We Need to Talk About Microsoft Quick Assist: An IT Security Primer

In the relentless race against cybercriminals, you can't afford to ignore hidden vulnerabilities. In the last few months, the Inversion6 MSSP and Incident Response teams   have been dealing with a new favorite for attackers—the Microsoft Quick Assist remote monitoring and management (RMM) tool. 

The purpose of RMM tools is straightforward: IT teams (helpers) use it to provide remote support to users (sharers) through a simple, shareable security code.  

Sounds harmless, right? Think again. 

For several years, threat actors have been using common RMM tools such as AnyDesk and ScreenConnect to trick victims and obtain a foothold onto systems. But Quick Assist is an even better attack vector because it is installed by default on most Windows 10 and Windows 11 machines. 

A tool can’t be bad if it came installed from Microsoft, right?  

Wrong. In fact, Quick Assist has quickly become a prime target for attackers via two primary scenarios: 

1. Tech Support Scams: 
   Victims are lured into a malicious website that displays fake infection messages and prompts them to call a number to remove the malware. After calling the number, the “support person” connects to their computer with Quick Assist, executes trivial commands to scare them, then extorts them for money. 

2. Social Engineering Attacks: 
   These more destructive attacks start with attackers bombarding a victim with spam messages to overwhelm them. The attacker then calls the victim (or sends a message via Microsoft Teams if security is lax) masquerading as IT personnel. Once they gain control via Quick Assist, they install backdoors that can pave the way for data theft, ransomware such as Black Basta or worse.  

Truth is, while Quick Assist might streamline IT support, it can be a real headache for security teams. Not only is it installed by default, it provides minimal activity logging and zero user control. This makes an attack harder to stop, and harder to investigate. 

This primer aims to help IT and security teams fight back by giving them a better understanding of this technology, along with a few critical tools to investigate a Quick Assist attack and protect themselves in the future. 

Where to Start?  

If your team suspects Quick Assist misuse, you need to act quickly and decisively with two primary goals in mind: Determining the start/end times of a session and figuring out whether the user granted consent for a system takeover. 

Where to find Quick Assist: 

Quick Assist is in two separate locations: 

1. C:\windows\system32\quickassist.exe 
   This location has been seen when Quick Assist is installed by default, mostly on Windows 10 systems. 

2. C:\ProgramFiles\WindowsApps\MicrosoftCorporationII.QuickAssist_[VERSION]__8wekyb3d8bbwe\Microsoft.RemoteAssistance.QuickAssist\QuickAssist.exe  
   This location has been seen with default installs on Windows 11 and when Quick Assist is installed through the Microsoft Store. Note that [VERSION] will show the Quick Assist version number. 

While running, Quick Assist executes the Edge WebView2 browser control program at C:\Program Files (x86)\Microsoft\EdgeWebView\Application\[VERSION]\msedgewebview2.exe.  

This embedded web control allows applications to render HTML pages. While Edge Webview2 can be run in other contexts, you will know its related to Quick Assist because it will have the parameters “--webview-exe-name=quickassist.exe”.  

Note that all programs executed  through Quick Assist are done under the normal parent-child relationship of the process tree in Windows,not under quickassist.exe or msedgewebview2.exe.  

In other words, if an attacker executes a task automation program such as PowerShell while connected via Quick Assist, the parent process of PowerShell will show as Window Explorer, not any of the Quick Assist processes. This makes it very difficult to determine whether it was the victim or the attacker who executed a process. 

Dissecting a Quick Assist Session 

Unfortunately, Windows provides very little evidence to show that a past Quick Assist session ever occurred. Luckily, there are still some ways to determine when and how Quick Assist was used on a system. 

Event Logs: 

If Quick Assist was installed from the Microsoft Store, it will log events in the Application log with event ID 0 and a source of “Quick Assist.” Many of these log events are nothing more than error messages, but some can supply useful information.  

For example, the launch time of QuickAssist.exe is logged in an event and can be correlated with other artifacts as seen below: 

Most of the logs will be in a JSON-like format starting with “Info” and containing “command” and “context” fields which log some Quick Assist activities. In some cases, the information in the event log will be truncated.

Events with the command “requestresponse” with context “beginsharing” indicate the Quick Assist sharer shared their screen with the helper. These are often accompanied by a result success value of “true,” as seen below: 

  When consent is granted to take control of a system, a context of “setsharingmode” and a sharing mode of “FullControl” is logged, as seen below.  

 

 

As with other events, a result of “true” value indicates consent was in fact granted to control the system. When this control is cancelled or removed, another “setsharingmode” command will be sent with the sharing mode set to “View”. 

Note: consent is only logged in versions of Quick Assist installed directly from the Microsoft Store (or included by default in Windows 11).  There is currently no known method for determining who granted consent for a takeover when dealing with other versions of Quick Assist. 

Finally, events with a command of “endsharing” are logged when sharing of the system is stopped and “sendappclose” commands are logged when Quick Assist is shut down. 

Execution Artifacts 

Whenever they are executed, the quickassist.exe and msedgewebview2.exe files create several additional files which can be used to show Quick Assist was launched, while also providing information on subsequent actions taken. 

The primary directory created by msedgewebview2.exe during a Quick Assist session is %APPDATA%\Local\Temp\RemoteHelp\EBWebView. Within this directory are the Chromium browser artifacts for the Quick Assist msedgewebview2.exe processes (Microsoft Edge is based on Chromium).  

Unfortunately, none of these artifacts track consent; however, they can be analyzed with any Chromium forensics tool, such as Hindsight to uncover timestamps for many of the network operations performed. Some URLs to pay attention to include: 

• https://remoteassistance.support.services.microsoft.com The first instance typically occurs several seconds after Quick Assist was launched. 

• https://remoteassistance.support.services.microsoft.com/screenshare Occurs shortly after screen sharing is enabled or the sharing code is typed in by the sharer. 

• https://remoteassistance.support.services.microsoft.com/status/ended Occurs when the sharing connection has been closed. 

In summary, following these trails can often help investigators determine the time window in which attackers had access to a system and potentially which programs were executed during this timeframe. 

Proactive Protection Options 

Unfortunately, Quick Assist cannot currently be configured to prevent it from running on a system, or to limit who can act as a helper or sharer. However, there are other options for getting in front of potential misuse, including: 

1. Removing Quick Assist: The easiest way to eliminate the threat is to simply uninstall and/or delete the Quick Assist tool. This should be combined with application denylisting via Microsoft’s AppControl and AppLocker to add additional attack hurdles and discourage unauthorized reinstallation. 

2. Blocking Access to Quick Assist: Firewalls, proxy servers and other network controls can be used to shut down Quick Assist by preventing communication with https://remoteassistance.support.services.microsoft.com (be aware this will also impact other tools such as Microsoft Intune Remote Help). Simply blocking access to the Remote Desktop Protocol (RDP) port will not work in this case, since both the Quick Assist sharer and the helper communicate indirectly  through several of Microsoft’s servers via the TLS 1.2 (TCP/443) protocol, rather than the typical TCP/3389. 

3. Carefully Monitoring Quick Assist: Endpoint telemetry tools (expanded logging, EDR, SIEM etc.) should be used to monitor for the launch of Quick Assist executions, allowing organizations to quickly detect and analyze the validity of each session.

 

Bottom line: dealing with Microsoft Quick Assist requires constant vigilance and proactive planning. It’s an easy way for IT to troubleshoot user issues, but the default installation, lack of logging and absence of controls also makes it easy for attackers to establish a foothold in your system.  

Need help addressing these challenges? Schedule a consultation with our team to learn more about proactively protecting your business.