Slamming the Door on Quick Assist Tech Support Scams and Abuse

Over the past month or so, I've worked a number of Incident Response engagements that in some way dealt with social engineering attack vectors. Sure, there are the Business Email Compromise (BEC) situations that end up coming our way that dig into the Microsoft 365 tenant, reviewing all the logs and ultimately discovering what happened and to whom. However, with the success of ClickFix threat campaigns, we have seen an uptick in cases that have started with the use of social engineered “tech support”.

This blog focuses on the Windows 10 and 11 provided tool Quick Assist. Quick Assist is a remote monitoring and management (RMM) utility that allows remote assistance. There are two (2) versions of Quick Assist, which can be identified by where they live on a Windows endpoint.

The newer editions of Quick Assist have greater logging features, so if that is present, you can take advantage of more useful pieces of evidence when you have to investigate

In many cases, the attack starts with a series of phishing messages received by unsuspecting users, which after those are sent they are followed up by an unsolicited call through Microsoft Teams. The attacker claims to work in IT and is working to do something about the phishing messages. This marks when the attacker posing as a "helper" makes contact as an initial step.

It’s important to note that the selection of Microsoft applications is deliberate because the attackers know they can expect the following:

• Teams is likely to be used and available anywhere a Microsoft Windows endpoint is used
• Quick Assist is included and enabled by default on Windows 10 and 11 workstations and laptops
• The barrage of phishing emails immediately before the Teams call artificially creates a problem to be solved and a sense of urgency, increasing the odds that the user will accept the Teams call and agree to take part in the Quick Assist session

Below are three (3) URLs that can be used for detection across the enterprise and have to do with outbound (egress) requests to legitimate Microsoft infrastructure:

The URL ending with roleselection represents the official start of the Quick Assist RMM session. The session is initiated, and the user is presented with a prompt to enter a temporary 6-digit session value, which the attacker provides.

The next URL has to do with the screensharing feature being enabled and started; at this point, the attacker has the ability to see the victim's screen (and potentially be provided control over the system allowed by the victim). Lastly, the URL ending with status/ended marks the end of the session. 

These indicators can be found in multiple places:

• On a web proxy
• When forensically examining endpoints
• Within the user’s browser cache history

It is helpful to train staff to look in all three (3) areas when suspecting a malicious takeover.

If you are fortunate enough that the user endpoint is running the Quick Assist that was installed from the Microsoft Store repository, then the updated capabilities and logging of that newer version can be helpful. Specifically, there will be Application Event Log records for these later versions of Quick Assist, and they can be identified in the Event Log as Quick Assist in the source field. Those records can provide essential dates and times of activities to piece together what happened.

Now for what you can DO about it. You have several options that you can employ in your environment. We can organize this into procedural and technical controls to consider, followed by evaluation.

• Discuss with IT the protocols (or rules) for contacting users. Ensure there are established procedural outlines to ensure remote ID validation. Drill this regularly throughout the year to ensure that new and veteran users have a consistent process to follow. Educate and test this. This should be documented in a playbook and followed.
• Next, talk to your staff/users. Encourage users to come forward about any occurrence that seems unusual or if they feel they might have been scammed. This is not the time for shame or worry—let them know that the enterprise supports them and there will be assistance to minimize the impact. Be sure to keep any commitments reasonable and within the capabilities of the organization.
• Let staff know that when the IT department reaches out to them, it will be through accepted means of communication. If at any time they receive Teams (or any other type of remote call) purporting to be IT that does not match the established identification rules in place, they must report their suspicions. Now is the time to devise how authentication between staff happens in a practical and professional way that maintains the security of the computing environment.
• In your education campaign about the dangers of unsolicited Teams calls and Quick Assist sessions, give the users on your team clear guidance on what correct tech support contact protocols look like through internal communication channels. Be sure to give them measurable steps to validate the IT calls as legitimate and the user is comfortable to proceed.

Testing this regularly is extremely important. This is where we begin getting into technical controls.

First, define your RMM solution policy. Reduce your perimeter of concerns by removing Quick Assist from endpoints if you don’t need it to conduct critical IT support functions. That means uninstall and preferably delete instances of the Quick Assist application from any local installation Microsoft Configuration Manager (formerly called SCCM). If you have application denylisting capability with Microsoft AppLocker or equivalent capability through your existing Endpoint Detection and Response (EDR) system, consider adding it so you are alerted when there are reinstallation attempts. If you really must use Quick Assist, remove that and then upgrade the organization’s deployment to use Remote Help for Microsoft Intune. This has features that enforce sign-in on both ends of the session, which increases accountability.

Consider employing a web proxy and URL filtering for the ingress and egress paths to the enterprise if you haven’t already. Ensure any solution put into place gives you the option to create URL filtering and alerting while you block Quick Assist traffic. Keep in mind that this will also affect Microsoft Intune Remote Help, so be sure to evaluate how it will impact your operations. This is so you have detection and alerting. If you proceed here, you can have the ability to search outbound traffic that refers to the Quick Assist URLs that were discussed earlier and alert on any matches. You will have the capability to know whether a host system and user have taken part in a Quick Assist session.

Once you have detection visibility, ensure the legitimate baselines of legitimate RMM tools are validated, and anything else that is not valid goes to alerting. This means an alert is generated if a Quick Assist session starts in an enterprise that uses a different RMM tool. Emails are sent out for response and ticketing to start the documentation processes for resolution.

Discuss with your network and your host forensic team members. The network techs will need to know that Quick Assist works over HTTP (TCP/443) and not the usual means, which most of us think about remote desktop (TCP/3389). Browser history records will be essential for any data relating to the previously discussed URLs. Ensure these checks are part of their host exams if there is a suspicion of remote assistance scams.

The last leg in the proactive response is to devise testing or evaluation of your controls. (In my time in the U.S. military, we would describe this phase as supervision.)

• Test to ensure that alerts are generated when expected, and processes are kicked off beginning at the user level and extending through the response chain with IT tech support, security practitioners, and leaders supporting. Your annual social engineering tests that come in the form of phishing test should incorporate some of these tech support scams.
• Network teams should be testing and evaluating the efficacy of network visibility and software deployment baseline tripwires. Expect them to determine if traffic goes to the Quick Assist URLs, or whether Quick Assist is being installed on endpoints. Be sure they are using playbooks and improving them as you test the capabilities.

Before we wrap up, I want to leave you with a few things to consider.

Think about how your IT team communicates with users in your business today. Do your people actually know what legitimate support looks like and, more importantly, what is suspicious? Make sure they know exactly what to do when something doesn’t feel right, because that gut reaction is often the first line of defense against remote assistance scams. Make sure they are aware this form of tech assistance scam is going around, and test that awareness. 

More importantly, don’t rely on users to always make the right call. Take steps to remove Quick Assist if you don’t need it, or upgrade to a more secure solution. Additionally, don't wait for an incident to find out your alerting and logging has blind spots. Take the preparatory steps now to make sure you have enough visibility and alerting in place so that if and when it happens, your team can respond quickly. Be sure to equip and train your staff so when they start to pull on a thread, the clues are actually there to find.

My hope is simple: Consider this topic and implement these suggestions to keep your network and staff secure. We want to help you keep attackers from ever getting that initial foothold to quietly spread through your network undetected, all under the guise of "help" that nobody asked for and nobody needs.

Additional References/Resources:

• https://support.microsoft.com/en-us/windows/protect-yourself-from-tech-support-scams-2ebf91bd-f94c-2a8a-e541-f5c800d18435
• https://www.microsoft.com/en-us/security/blog/2024/05/15/threat-actors-misusing-quick-assist-in-social-engineering-attacks-leading-to-ransomware/
• https://techcommunity.microsoft.com/blog/microsoftsecurityexperts/phish-click-breach-hunting-for-a-sophisticated-cyber-attack/4267916