Quick Assist Full Control Mode Enabled
Detection stack
- AIDR
- Alert
- ETL
- Query
Summary
Threat actors are abusing Microsoft Quick Assist to support social engineering schemes and fake help desk operations. When Full Control sharing mode is enabled, the attacker can gain complete interactive access to the victim’s device. This technique is often used as an early step in ransomware incidents and other forms of unauthorized remote access.
Investigation
Investigators should review Windows Application logs related to the Quick Assist provider, with particular attention to setsharingmode actions containing FullControl parameters. These events should be correlated with QuickAssist.exe process telemetry, including parent processes and command-line details. It is also important to confirm whether the session matches a legitimate IT support request and authorized support personnel.
Mitigation
Organizations should assess whether Quick Assist needs to remain enabled across the environment or whether it should be restricted by policy, especially on high-value systems. Enforcing stricter controls on remote assistance tools can help reduce the attack surface. Continuous monitoring of application logs for unauthorized transitions into full-control sharing mode is also recommended.
Response
If malicious use is confirmed, terminate the Quick Assist session immediately and isolate the affected host. Reset any credentials that may have been exposed during the interactive session. Preserve application logs and related session telemetry for forensic analysis before starting remediation.
Attack Flow
We are still updating this part. Sign up to get notified
Notify MeSimulation Execution
Prerequisite: The Telemetry & Baseline Pre-flight Check must have passed.
Rationale: This section details the precise execution of the adversary technique (TTP) designed to trigger the detection rule. The commands and narrative MUST directly reflect the TTPs identified and aim to generate the exact telemetry expected by the detection logic. Abstract or unrelated examples will lead to misdiagnosis.
-
Attack Narrative & Commands: An adversary initiates a social engineering attack, convincing a user to open Microsoft Quick Assist. Once the connection is established, the adversary attempts to escalate their privileges within the session by requesting “Full Control” mode. This action triggers a specific event within the Quick Assist provider in the Windows Application log, containing the string
FullControl*setsharingmode*. This simulation bypasses the actual UI interaction by manually injecting the specific event into the Windows Application log to validate that the detection logic correctly parses theparam1field. -
Regression Test Script:
# Simulation Script: Manually inject the Quick Assist event to trigger detection # Note: This requires administrative privileges to write to the Application log. $provider = "Quick Assist" $eventId = 0 $param1 = "FullControl*setsharingmode* - User: Attacker" # We use the EventCreate utility or .NET to simulate the provider event # Since we cannot easily spoof a specific provider via CLI without a driver, # we simulate the log entry structure expected by the rule. Write-EventLog -LogName Application -Source "Quick Assist" -EventId $eventId -EntryType Information -Message "Mode changed: $param1" Write-Host "Simulation event injected into Application Log." -
Cleanup Commands:
# No direct cleanup is required for event logs, but in a real environment, # one would clear the specific event if possible, or simply note the time of injection. Write-Host "Simulation complete. No system changes were made to the OS configuration."