Agent Foskett Investigation • Social Engineering • Quick Assist • Microsoft Defender XDR • KQL
The User Never Shared Their Password — They Shared Their Screen
“I never gave anyone my password.”
The user was absolutely certain.
No password in an email. No credentials typed into a strange website. No MFA code read over the phone.
And yet somebody had been operating their computer.
Agent Foskett asked one more question:
“Did anybody ask you to share your screen?”
The Password Wasn't The Entry Point
The attacker did not need the user to reveal a secret. They needed the user to approve a legitimate remote-support session.
✓ Reconstruct the remote-support timeline
✓ Separate user consent from attacker legitimacy
✓ Hunt the activity performed after control was granted
The help desk called
The user had been receiving a flood of unwanted messages. Then somebody contacted them claiming to be from IT support and offered to fix the problem. The caller sounded professional, knew enough technical language to be convincing and asked the user to open Quick Assist.
No password requestThe caller never asked the user to disclose their Microsoft 365 password.
Legitimate Microsoft toolQuick Assist was already familiar enough to look safer than downloading an unknown remote-access program.
User approvalThe user entered the supplied code, shared the screen and later approved the request for control.
The user's statement was true
The investigation initially focused on stolen credentials because that is where many account-compromise investigations begin. But the user's statement mattered: they had not knowingly shared their password. The attacker had taken a different route.
Investigation principle: do not force the evidence to fit the first theory. A user can truthfully say “I never shared my password” and still have granted an attacker interactive access to the device.
Find the remote-support activity
On a Defender-onboarded Windows endpoint, process telemetry can help establish whether Quick Assist-related processes were active around the reported support call. Process names and implementation details can change, so treat this as a starting point and validate against the telemetry in your tenant.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
let TargetDevice = "WKSTN-407";
DeviceProcessEvents
| where Timestamp > ago(7d)
| where DeviceName startswith TargetDevice
| where FileName in~ ("QuickAssist.exe", "msedgewebview2.exe")
or ProcessCommandLine has "Quick Assist"
| project Timestamp, DeviceName, AccountName,
FileName, ProcessCommandLine,
InitiatingProcessFileName,
InitiatingProcessCommandLine
| order by Timestamp asc
The timeline changed everything
14:07User receives a Teams call from somebody presenting themselves as IT support.
14:12Quick Assist starts on WKSTN-407.
14:15User shares the screen and approves control.
14:18Command-line activity begins on the endpoint during the support session.
14:23A second remote-management utility is downloaded.
14:31The fake support call ends. The follow-on access does not.
Look at what happened during the session
The presence of Quick Assist alone is not malicious. It is a legitimate support application. The stronger evidence comes from correlating the session window with the processes and commands that appeared while the remote party had control.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
let TargetDevice = "WKSTN-407";
let IncidentStart = datetime(2026-09-03 14:05:00);
let IncidentEnd = datetime(2026-09-03 14:45:00);
DeviceProcessEvents
| where Timestamp between (IncidentStart .. IncidentEnd)
| where DeviceName startswith TargetDevice
| project Timestamp, DeviceName, AccountName,
FileName, ProcessCommandLine,
InitiatingProcessFileName,
InitiatingProcessCommandLine,
InitiatingProcessAccountName
| order by Timestamp asc
Key distinction: legitimate software can be used for an illegitimate purpose. Do not classify the application as malware simply because an attacker abused it.
The attacker was using the user's hands as the initial-access control
Nothing needed to exploit Windows to begin the session. The user performed the expected approval steps because they believed the person on the other end was authorised support. The security failure was therefore not a broken authentication protocol. It was misplaced trust.
Social engineeringThe attacker established credibility before requesting remote access.
ConsentThe user intentionally approved the session — but under a false understanding of who the helper was.
Remote controlOnce control was approved, the attacker could interact with the desktop and perform actions in the user's context.
Follow the network activity too
Network telemetry around the same incident window can help identify connections made by processes on the endpoint and expose follow-on downloads or infrastructure contacted after the remote session began.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
let TargetDevice = "WKSTN-407";
let IncidentStart = datetime(2026-09-03 14:05:00);
let IncidentEnd = datetime(2026-09-03 15:00:00);
DeviceNetworkEvents
| where Timestamp between (IncidentStart .. IncidentEnd)
| where DeviceName startswith TargetDevice
| project Timestamp, DeviceName, ActionType,
InitiatingProcessFileName,
InitiatingProcessCommandLine,
RemoteUrl, RemoteIP, RemotePort
| order by Timestamp asc
Microsoft has seen this technique in real attacks
Microsoft Threat Intelligence has documented threat actors impersonating IT or help-desk personnel and misusing Quick Assist for initial access. In observed campaigns, users were persuaded to allow screen sharing and then approve remote control, after which attackers performed follow-on activity including downloading additional tooling.
Important: this Agent Foskett scenario is an educational investigation pattern. Finding Quick Assist does not mean a device was part of any specific Microsoft-tracked campaign or threat actor operation.
What Agent Foskett checked
User interviewWhat exactly did the caller say, and what actions did the user remember approving?
Teams evidenceWas there an unexpected message or call presenting itself as support?
Endpoint timelineWhen did Quick Assist and related processes appear?
Child processesWhat commands or tools executed during and immediately after the session?
Network activityWhich destinations were contacted after control was granted?
PersistenceWas another RMM tool, scheduled task, service or other access mechanism established?
What the evidence does not prove by itself
Quick Assist usage is not automatically suspicious. Genuine support teams use remote assistance every day. A Teams call from an external tenant, a Quick Assist process, a remote-control session or a newly downloaded tool each requires context. The conclusion comes from the combined timeline, user account, support process, endpoint activity and subsequent behaviour.
The defensive lesson
If an organisation does not use Quick Assist, Microsoft documents options to remove or block it. Where remote support is required, organisations should define an approved support channel, teach users how support staff identify themselves, investigate unexpected remote-support requests and monitor the activity that follows remote sessions.
Agent Foskett rule: never treat “the user approved it” as proof that the person requesting access was legitimate.
Related investigations
The Password Was Never Stolen — The Browser Cookie WasAnother case where the password was not the mechanism that explained the compromise.The Teams Message Contained the Phishing Link — Not the EmailFollow the social-engineering trail when the initial contact moves away from email.The Scheduled Task Looked Legitimate — Until We Checked Who Created ItContinue into persistence and creator attribution after initial access.
Final thought
The investigation began with a question about credentials. The user kept insisting they had never given anybody their password, and the evidence never proved otherwise. The breakthrough came when Agent Foskett stopped asking what secret had been stolen and asked what access had been granted. A fake support call, a legitimate remote-assistance tool and one approval prompt had given the attacker the foothold they needed. The password was never shared. The screen was.
The Logs Already Knew! 🔎
The Logs Already Knew! 🔎
