Quick Assist vs Remote Help: the free one is a social-engineering vector, and the paid one is why

There is an application on almost every Windows 11 device in your fleet that lets a complete stranger take full control of the screen, the keyboard and the mouse. It needs no domain membership, no Intune enrolment, no licence and no policy. The person being helped does not have to sign in to anything. The entire authorisation step is a six-digit number read out over the phone. It is called Quick Assist, Microsoft ships it, and it is the front door for an entire class of tech-support scam and at least one documented ransomware campaign.

Microsoft also ships the grown-up version. It is called Remote Help, it is part of the Intune Suite, and it authenticates both sides against your own tenant. This post explains what each tool actually is, how each one authorises a session, what each one writes to disk, and how to make a deliberate choice between them instead of leaving the free one switched on by accident.

The problem: a six-digit code is the entire authorisation

Start with what these two applications are, in plain English, because the names are unhelpfully similar.

Quick Assist is a small remote-support app that Microsoft describes as an application that "enables a person to share their Windows or macOS device with another person over a remote connection". One person is the helper. The other is the sharer. The helper generates a code, reads it to the sharer, and once the sharer types it in and clicks Allow, the helper sees the screen. If the helper then asks for control and the sharer clicks Allow again, the helper has the sharer's keyboard and mouse.

Remote Help is a separate application that Microsoft describes as "a cloud-based remote support solution that allows IT support teams to connect securely to an end-user's device for real-time assistance". Same two roles, same screen sharing, completely different trust model: both parties must sign in with a Microsoft Entra ID account belonging to your organisation, for every session.

Here is the difference that matters, stated as bluntly as the documentation states it.

Read the "who must authenticate" row again. The sharer authenticating to nothing is not a bug, it is the design goal. Quick Assist exists so that a consumer with a broken laptop can be helped by a relative or by Microsoft Support, and consumers do not have tenants. The problem is that the same app is preinstalled on the managed Windows 11 device sitting on a corporate desk, where the design goal is exactly backwards.

Note what the attacker never has to do in that chain. No exploit. No credential theft. No signed driver, no token replay, no unpatched CVE. They phone a human being and read out a number.

Why it happens: Quick Assist was never built for tenant control

To manage something you first have to know what it is made of and where it comes from. Quick Assist has changed shape twice, which is why half the blocking advice on the internet is now wrong.

How Quick Assist is delivered today

Originally Quick Assist was a Feature on Demand, or FOD: an optional Windows component installed with DISM (Deployment Image Servicing and Management, the servicing tool built into Windows). Microsoft's Features on Demand reference still lists it, and it is explicit about the change:

So on Windows 11 there is no capability to remove and no quickassist.exe in System32. There is an MSIX package, preinstalled, kept current by the Microsoft Store, published under the identity MicrosoftCorporationII.QuickAssist. That single fact invalidates every DISM-based removal script written for Windows 10, and it is why the app can quietly come back after you remove it.

How a Quick Assist session is authorised, step by step

Microsoft documents the sequence. Following it makes clear where the only trust decision lives.

1. Both people launch Quick Assist. On Windows 11 that is Start, All apps, Quick Assist, or the keyboard shortcut CTRL + Windows + Q.
2. The helper selects Help someone and signs in with a Microsoft account or a Microsoft Entra ID account. Quick Assist contacts the Remote Assistance Service and gets back "a time-limited security code".
3. An RCC chat session is created, and the helper's instance of Quick Assist joins it.
4. The helper reads the six-digit code to the sharer, "over the phone or with a messaging system".
5. The sharer types the code into the Security code from assistant box. Their Quick Assist instance uses the code to join that specific session.
6. The sharer is prompted for permission and clicks Allow. Screen sharing begins.
7. The helper may then select Request control, and the sharer gets a second Allow or Deny prompt.
8. Quick Assist starts RDP control and connects to the RDP Relay service. Video flows to the helper over HTTPS on port 443; input flows back the same way.

Steps 6 and 7 are the whole security model: two clicks by a person who has just been told a convincing story. There is no step where the service checks whether the helper belongs to the same organisation as the sharer, because there is no organisation in the picture.

What each tool needs to reach on the network

Both tools terminate at Microsoft-run relays. Microsoft publishes the required destinations for each, and the two lists overlap deliberately, which matters later when you decide how to block one without killing the other.

What Remote Help gives you that Quick Assist structurally cannot

Microsoft's own Quick Assist article now carries an Important box recommending Remote Help for single-tenant organisations, and lists the reasons: Conditional Access enforcement, role-based access control, session logging and auditing, data sovereignty and tenant isolation, and integration with Microsoft Defender for Endpoint. In practice the documented capabilities break down like this.

Where Defender fits

Be precise here, because this is where a lot of blog posts overclaim. There is no attack surface reduction rule and no Defender setting named after Quick Assist. What Microsoft does document is detection of what happens after the session is granted. The Storm-1811 research names these detections, and they are the ones worth hunting for alongside any Quick Assist launch.

How to verify: what is installed, what blocks it, what it leaves behind

Before changing anything, find out what a given device actually has. Everything in this section is read-only.

Is Quick Assist present, and how did it get here?

The first command asks the Appx subsystem whether the Quick Assist MSIX package is registered for the current user, and prints the identity fields you need for an app-control rule. The second asks DISM whether the old Feature on Demand exists at all on this build.

Two follow-ups matter. Get-AppxPackage -AllUsers shows which profiles have it registered, and Get-AppxProvisionedPackage -Online shows whether the package is staged in the image, which decides whether a brand-new user profile gets it again. Both need elevation, and on a hardened device the provisioned query can still return Access is denied - which is a failed read, not a clean result.

The binaries involved

Event Viewer: one tool logs, the other does not

This is the single most important operational difference, and it is worth stating without softening it. Microsoft publishes no Event IDs for Quick Assist, because Quick Assist writes nothing locally. The documentation says: "No logs are created on either the helper's or sharer's device." Remote Help, by contrast, "logs session details to the Windows Event Logs on the device of both the helper and sharer".

Because there are no first-party Quick Assist events, the useful Event IDs come from the app-control layer that blocks or permits the package. Those are documented, and they are how you prove a block is working.

Log files on disk

Quick Assist has none. Remote Help has documented ones, and there is a delightful piece of archaeology in the file names.

Services and scheduled tasks

Neither Quick Assist nor Remote Help installs a scheduled task of its own that Microsoft documents. Remote Help ships RHService.exe, but Microsoft documents only its file path in firewall guidance, not a service short name, so treat the binary as the reliable artefact.

Registry: what actually exists, and what does not

There is no registry key that turns Quick Assist off. What exists are the app-deployment and Store policies that decide whether a user can install or launch a Store app at all, plus the legacy Remote Assistance policy that is frequently mistaken for a Quick Assist control.

Run the exposure report

The companion script for this post pulls all of the above together into one read-only pass, and refuses to report a clean result if any read failed. Download it, then run it elevated.

The fix: pick one tool on purpose and enforce the choice

There are only three defensible end states. Remote Help licensed and deployed with Quick Assist blocked. Quick Assist deliberately retained with users trained and Defender for Endpoint watching. Or no remote-support tool at all. The indefensible state is the default one: Quick Assist present because nobody removed it.

Step 1: turn on Remote Help in the tenant

Remote Help is off until you enable it, and it needs licences for helpers and sharers alike. Do this first, so your helpdesk has something to use before you take Quick Assist away.

1. Sign in to the Microsoft Intune admin center.
2. Go to Tenant administration, then Remote Help.
3. On the Settings tab, set Enable Remote Help to Enabled. It is Disabled by default.
4. Decide on Allow Remote Help to unenrolled devices. Leave it Disabled unless you genuinely need it, because auditing on unenrolled devices is limited.
5. Decide on Disable chat. Chat is on by default, with this setting at No.
6. Select Save.
7. Wait. Microsoft documents that new or trial licences can take from 30 minutes to 8 hours to activate, and sessions may keep reporting Remote Help as not enabled in the meantime.

Step 2: grant only the permissions each tier needs

This is the control Quick Assist has no equivalent for. Remote Help permissions are Intune role-based access control permissions, assigned through a role assignment with scope groups.

Microsoft is explicit about the combination required: a helper needs Remote Tasks - Offer remote assistance, plus Remote Assistance Connector - Read, plus at least one of the Remote Help permissions. The built-in Help Desk Operator role contains all of them. The built-in School Administrator role contains all except Unattended.

Step 3: deploy the Remote Help app to Windows devices

Remote Help must be installed on every device that will take part, helper or sharer. The simplest route is the Enterprise App Catalog. The documented manual route is a Win32 app.

1. Download the installer from https://aka.ms/downloadremotehelp and rename the file to remotehelpinstaller.exe. The command lines below depend on that exact name.
2. Repackage it as a .intunewin file with the Microsoft Win32 Content Prep Tool.
3. In Intune, add a Windows app (Win32) and upload the package.
4. For Install command line, enter remotehelpinstaller.exe /quiet acceptTerms=1.
5. For Uninstall command line, enter remotehelpinstaller.exe /uninstall /quiet acceptTerms=1.
6. To opt out of the app updating itself, append enableAutoUpdates=0. Both switches are case sensitive.
7. On Detection rules, choose Manually configure detection rules, then add a File rule: path C:\Program Files\Remote Help, file RemoteHelp.exe, detection method String (version), operator Greater than or equal to, and the version you are deploying.
8. Assign to device groups. Microsoft notes Remote Help is applicable when targeting device groups, not user groups.

To get the version string for that detection rule, install it once by hand and read the file version.

Step 4: apply Conditional Access to Remote Help

Because helpers gain interactive access to user devices, Microsoft recommends requiring multifactor authentication or compliant-device status for helper accounts. Conditional Access targets Remote Help through a service principal you create once.

1. Open PowerShell as administrator with the Microsoft Graph PowerShell module available.
2. Run Connect-MgGraph -Scopes "Application.ReadWrite.All" and sign in with an account that can consent.
3. Create the service principal for the Remote Assistance Service application ID 1dee7b72-b80d-4e56-933d-8b6b04f9a3e2. The resulting display name is RemoteAssistanceService.
4. Run Disconnect-MgGraph.
5. In the Microsoft Entra admin center, build or edit a Conditional Access policy and target Resources (formerly cloud apps), selecting RemoteAssistanceService.
6. Require MFA, or compliant device, or both, for your helper group.

Step 5: remove Quick Assist

Microsoft documents exactly one removal command, and it is an Appx removal, not a DISM one.

The equivalent for a fleet is a detection-and-remediation script pair in Intune, under Devices, Scripts and remediations: detect the package with Get-AppxPackage and exit 1 when found, then remediate with the command above. The manual route for a single machine is Settings, Apps, Installed apps, Quick Assist, the ellipsis, then Uninstall.

Step 6: block it, because removal alone does not hold

Now the honest part about policy coverage.

So enforcement comes from app control. The Group Policy route uses AppLocker packaged-app rules.

1. Open the Group Policy Management Editor on a policy that targets your Windows clients.
2. Navigate to Computer Configuration, Windows Settings, Security Settings, Application Control Policies, AppLocker, Packaged app Rules.
3. If the collection is empty, right-click and choose Create Default Rules first. Without an allow rule, enforcing packaged-app rules blocks every Store app, and AppLocker logs event 8027 to tell you so.
4. Right-click, choose Create New Rule, set the action to Deny for Everyone.
5. Choose Use an installed packaged app as a reference and pick Quick Assist, or enter the publisher CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US with package name MicrosoftCorporationII.QuickAssist.
6. Set the version range to any version, so a Store update does not walk around your rule.
7. In AppLocker properties, set Packaged app Rules to Audit only first. Confirm you see 8021 events for Quick Assist and nothing else, then switch to Enforce rules.
8. Confirm AppIDSvc is running on the clients, or none of this is evaluated.

1. Go to Devices, Configuration, then Create.
2. Platform Windows 10 and later, profile type Templates, then Custom.
3. Name the profile, for example AppLocker - deny Quick Assist.
4. Add a row. Set OMA-URI to ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/{aaaaaaaa-0b0b-1c1c-2d2d-333333333333}/StoreApps/Policy.
5. Set Data type to String and paste your exported Appx rule collection XML as the value.
6. Assign to a pilot device group first. Because the node reboots the device automatically, schedule accordingly.
7. Verify on a client with Get-AppxPackage still returning the package, but launching Quick Assist failing and event 8022 appearing in Packaged app-Execution.

If you already run App Control for Business - the feature formerly called Windows Defender Application Control - you can deny the package family name instead. That is a stronger control, but read the warning first.

Step 7: stop the reinstall

Removal plus a launch block still leaves the Store listing. Close that loop with the Store and Appx policies from the registry table, configured properly through policy rather than by editing keys.

1. For the retail catalogue, go to Windows Components, Store, and enable Only display the private store within the Microsoft Store.
2. For standard-user installs, go to Windows Components, App Package Deployment, and enable Prevent non-admin users from installing packaged Windows apps. This is Enterprise and Education only.
3. If you want the blunt instrument, Windows Components, Store, Disable all apps from Microsoft Store stops every Store-originated app launching. Test this hard; it hits far more than Quick Assist.
4. In Intune, the same settings appear in the settings catalog under the ApplicationManagement area, matching the CSP names in the registry table above.

If you decide to keep Quick Assist

That is a legitimate choice for organisations without Intune Suite licensing, but it has to be an active decision with compensating controls. Microsoft's own user-facing guidance is the baseline: never allow a connection from someone claiming to be IT support unless you initiated the contact, do not grant access to anyone claiming urgency, and never share credentials during a session. Microsoft also states it will never contact users unsolicited to request device access. Pair that message with Defender for Endpoint coverage for the post-access detections listed earlier, and with the reporting route Microsoft publishes for tech-support scams.

Proof it worked: reading the exposure report

Below is a genuine run of the companion script on a live Windows 11 Enterprise device, build 26200, with the computer name, user name and App Control policy identifiers replaced. It is the "before" picture for a typical unmanaged-for-this-risk device: Quick Assist present, no Remote Help, nothing blocking it.

After you have deployed Remote Help, removed the package and applied an AppLocker deny rule, the same script should report Quick Assist as ABSENT, Remote Help as PRESENT, and App control as BLOCKED with the rule named. The independent confirmation that the block is live comes from the AppLocker channel: a user attempting to launch Quick Assist produces event 8022 in Microsoft-Windows-AppLocker/Packaged app-Execution, naming the package.

On the Remote Help side, your central evidence lives in Intune rather than on the device.

1. The Monitor tab shows a count of active sessions and historical data.
2. The Remote Help sessions tab lists past sessions with the helper (Provider ID), the sharer (Recipient ID), the device, the start and end times, and the type of control session.
3. Records persist for 30 days on Microsoft servers, and only metadata is stored - no screen images and no keystrokes.
4. Cross-check with Tenant administration, Audit logs, where Remote Help session audit entries are also written.
5. Remember the documented gap: use of the Windows elevation capability is not reported in the Remote Help sessions report.

Compare that with what you can prove about a Quick Assist session after the fact: nothing on the device, and nothing you can query centrally. That asymmetry is the argument. It is not that Quick Assist is malware; it is that when a Quick Assist session goes wrong, you have no record that it happened.

References

• Use Quick Assist to help users - Microsoft Learn. Authentication model, endpoint list, session flow, the "no logs are created" statement, the documented disable and uninstall methods, and the Remote Help recommendation.
• Plan for Remote Help with Microsoft Intune - Microsoft Learn. RBAC permission table, prerequisites and licensing, helper and client modes, network considerations, data and privacy.
• Deploy Remote Help with Microsoft Intune - Microsoft Learn. Tenant enablement steps, download link, Win32 install command lines and detection rule, firewall executables, Conditional Access service principal.
• Troubleshoot and monitor Remote Help - Microsoft Learn. Session reports, the installer log file names, and the Microsoft-Windows-RemoteHelp event channel path.
• Available features on demand - Microsoft Learn. The App.Support.QuickAssist~~~~0.0.1.0 capability and its retirement after Windows 11 build 22572.
• AppLocker CSP - Microsoft Learn. The ApplicationLaunchRestrictions/<Grouping>/StoreApps/Policy OMA-URI and packaged-app rule XML.
• Manage packaged apps with App Control - Microsoft Learn. Package Family Name rules and the all-or-nothing PFN warning.
• Using Event Viewer with AppLocker - Microsoft Learn. Event IDs 8020 to 8040.
• ApplicationManagement Policy CSP - Microsoft Learn. RequirePrivateStoreOnly, DisableStoreOriginatedApps, BlockNonAdminUserInstall and their Group Policy mappings.
• Network endpoints for Microsoft Intune - Microsoft Learn. The Remote Help endpoint sets 181, 187 and 188.
• Solve PC problems remotely using Quick Assist - Microsoft Support. The end-user flow and the six-digit code.
• Threat actors misusing Quick Assist in social engineering attacks leading to ransomware - Microsoft Security Blog. The Storm-1811 and Black Basta chain, the blocking recommendation, and the Defender detection names.

Community deep-dives, each fetched and confirmed to be on topic: