Quick Assist: Friend or Foe? How adversaries can exploit this tool and how can you defend?

The blog post will cover few security risks with it and how you can detect malicious activity in your environment.

👍 Previous Work

There were few articles that were published now-and-then since 2018. Most of these articles cover how adversaries can abuse this tool. I express gratitude to all the individuals who have contributed their efforts to disseminating knowledge, enabling us to safeguard ourselves. My research indicated very little around defense against these attacks. The following list might not be exhaustive. If you believe, I missed something, please do reach out. I'd be happy to include them:

🎯 Firstly, Is it a 0day/exploit/vulnerability?

NO. Here's a quick list of facts that might answer you.

  • Quick Assist is a legitimate utility published by Microsoft for facilitating remote support/diagnostics.

  • Presence of Quick Assist itself isn't a vulnerability. Just an increased attack surface.

  • It's not a vulnerability or a 0day, just an abuse of legitimate software. (Pretty much like any other LOLBIN).

  • Usage of Quick Assist isn't inherently malicious. However, depending on our organization, if you're already using another Remote assistance tool, usage of this is suspicious and it's a good idea to disable it.

🚨 Active Exploitation

Although I didn't find this tool be used very widely, few instances of this being exploited have been identified:

In addition to these, I saw several reddit posts and scan requests for "quickassist.exe" file on popular malware scanning platforms such as Virus Total indicating they are suspected to be a part of incident. However, we need to take them with a pinch of salt as people tend to randomly upload stuff on VT just out of mere low confidence suspicion.

🤔 What's Quick Assist?

Quick assist is a stock software that comes pre-installed with all versions of desktop operating systems starting from Windows Vista. To know more about Quick Assist, you can learn more at Microsoft's documentation here.

😼 How can adversaries abuse Quick Assist?

The attack scenario is very simple.

  • An adversary would open QuickAssist.exe on their endpoint, click on Help Someone and for the first time, it'll ask for an account to be logged in. It's important to note that a simple Microsoft account (can be created with outlook.com email) can be used here.

  • A code is generated and this code is shared by an adversary to the victim and with a little bit of social engineering, the adversary need to trick the user to

  • The adversary needs to share the code with the victim, entice the victim to enter the code and accept the screen sharing. In addition, the adversary can also request control. While it seems a bit complex (or unreal), you'd be surprised to know the amount of scams that are currently done via Teamviewer or AnyDesk using the same modus-operandi. Considering that this reduces an additional step of downloading a remote control software, it's more easier than ever.

🤑 Why it's a big deal?

  • Quick Assist is available on Windows by default, and this would reduce the effort required for scamming people is less when compared to leveraging Teamviewer/Anydesk.

  • Attack surface is large as many organizations have Windows for their endpoints. Considering this is available by default, Attack surface is unusually large.

🤘 How to detect malicious activity?

Considering that you have enabled Process Command line logging or Sysmon, the following query can be used.

KQL Query:

winlog.event_data.Image: *\\msedgewebview2.exe and winlog.event_data.CommandLine: *webview-exe-name=quickassist.exe*

ES|QL:

from winlogbeat* 
| where winlog.event_data.Image like "*?msedgewebview2.exe"
| where winlog.event_data.CommandLine like "*webview-exe-name=quickassist.exe*"

Alternatively, the following behavior can be used to identify the usage of Quick Assist. A combination of all the following artifacts could be used. These can be used with XDR being enabled.

Sigma Rule for usage with SIEMs:

title: Quick Help session initiated
id: d06bd2bc-c2ef-4445-b589-1aec52d4a8b6
status: experimental
description: Detects a suspicious process creation as SYSTEM user (suspicious program or command line parameter)
references:
    - 
author: Subhash Popuri (@pbssubhash)
date: 2024/02/18
modified: 2024/02/18
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        - Image|endswith:
           - '\msedgewebview2.exe'
        - CommandsLine|contains:
           - '--webview-exe-name=quickassist.exe'
    condition: selection
falsepositives:
    - Legitimate usage of Quick Help (very unlikely in enterprises using an alternative remote control software)
level: high

🔐 How to prevent Quick Assist from being used?

  • If your organization is using any remote control/remote assistance disagnostic tool such as LogMeIn, etc, you'd most likely not require this. Hence disable this.

  • As an individual user, you might require this at some point but for someone who's non technical (say your older family members), block the access. You can block Internet access to QuickAssist.exe using the following command:

Using App locker, you can easily disable access to Quick Assist. Here's how:

  1. Open Group Policy Editor > Windows Settings > Application Control Policies > App Locker

  1. Create Default rules (if you don't have Applocker installed already)

  1. Add QuickAssist.exe to the blocklist. This can be achieved by Executable Rules (Right click) > Create New Rule > Deny > File Hash > Browse File and select the location of executable.

For Non store apps, the location of the file is:

C:\Windows\System32\QuickAssist.exe

For instances where Quick Assist is downloaded from store:

C:\Program Files\WindowsApps\MicrosoftCorporationII.QuickAssist\Microsoft.RemoteAssistance.QuickAssist

💂‍♂️ Conclusion

Quick Assist is a natural choice for Remote Support and I'm unsure why I didn't see much legitimate usage around this (as compared to TeamViewer or AnyDesk). The exploitation is very easy because of reasons mentioned above. I'd be surprised if this wasn't being exploited already. Also, it'd be nice for Microsoft to add a control for domain locking where if a machine is domain joined (AAD), by default only users from the same domains can request control. This would deter adversaries attempting to abuse this, to some extent.

I'd highly recommend securing yourself against this TTP using the detection ideas presented.

Last updated