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.
Version | Location / Attribute |
|---|---|
Older edition | Present within C:\Windows\System32\ |
Newer edition | Present within C:\ProgramFiles\WindowsApps\MicrosoftCorporationII.QuickAssist_<VERSIONVALUE>__8wekyb3d8bbwe\ |
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:
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:
URL | Description |
|---|---|
https[:]//remoteassistance.support.services.microsoft[.]com/roleselection | Quick Assist Session Starts |
https[:]//remoteassistance.support.services.microsoft[.]com/screenshare | Quick Assist Session Screenshare Begins |
https[:]//remoteassistance.support.services.microsoft[.]com/status/ended | Quick Assist Session Ends |
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:
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.
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.)
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.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。