SOC Prime Bias: Medium

04 Jul 2026 06:57 UTC

Quick Assist Full Control Mode Enabled

Author Photo
SOC Prime Team linkedin icon Follow
Quick Assist Full Control Mode Enabled
shield icon

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 Me

Simulation 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 the param1 field.

  • 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."