Interactive security simulation · approximately 6 minutes

Let mefix that for you.

Your inbox suddenly fills with hundreds of messages. Then someone from “IT” calls and says they already know what is wrong.

1,247 messages received in nine minutes.

The software in this simulation is legitimate. The person asking you to use it is not.

Fictional company and people. Based on publicly reported abuse of remote-support tools.
The setup

The attacker creates the problem. Then offers to solve it.

You work in operations at Harborline Systems. It is 9:42 on a Wednesday morning.

Your inbox has become almost unusable. Order confirmations, mailing-list subscriptions and account-registration emails are arriving faster than you can delete them.

While you are trying to understand what happened, an incoming Teams call appears from Harborline Service Desk.

You have not opened a support ticket.

09:42
Harborline Service Desk is callingNo ticket opened · External Teams account · Problem already known
Wednesday · 09:42 · Harborline Systems Inbox under attack
📁
Projects
📄
Quarterly plan
🗑️
Recycle Bin
IT
Harborline Service Desk
Incoming Teams call External
Decline
Accept
Harborline Service DeskLIVE
IT
Daniel · Service Desk
Live transcript
Quick Assist — □ ✕
Screen sharing with Daniel
REMOTE SESSION ACTIVITY09:51
T
📁
◉ ᯤ 🔊09:42
17/07/2026

Debrief

The help was the attack.

Nothing in the remote-support window needed to be fake. The attacker only needed you to believe the person on the other end belonged there.

Independent verification
Access granted
Reported promptly

How the attack is built

1

Create confusion

A sudden flood of email makes the victim believe something is already wrong and makes normal work difficult.

2

Arrive as the explanation

The fake technician calls while the problem is happening. Their knowledge of the flood feels like proof that they are legitimate.

3

Use trusted software

Quick Assist is a real Microsoft tool. A genuine application window says nothing about who is operating the other side of the session.

4

Turn consent into access

The employee enters the code, shares the screen, grants control and approves any later prompts. Each step appears small on its own.

5

Work through the employee

The attacker may use the victim to approve elevation prompts, expose sensitive information or allow additional persistence—all inside an apparently normal support call.

The rule

An unexpected support call is not verification.

End the contact and reach your service desk through a channel you find yourself. A ticket number, familiar company name, real software and knowledge of your problem can all be part of the story.

Stop · Verify · Report

1
Stop before entering a code.

Do not open a remote session because an unsolicited caller tells you to. The code connects you to the person who generated it.

2
Verify independently.

Use your internal helpdesk portal, a known phone number or a new conversation started from the company directory. Do not rely on details supplied during the suspicious contact.

3
End access immediately if unsure.

Close the remote-support session or disconnect the device from the network, then contact security. Do not continue because you have already allowed the first step.

4
Report even when nothing obvious happened.

Security may need to review the device, revoke sessions and identify other employees receiving the same call.

Built as a personal learning project using fictional people and a fictional company. The attack pattern is based on public reporting from Microsoft on the misuse of Quick Assist in social-engineering attacks and guidance from CISA on malicious use of legitimate remote-access software. No live remote connection, executable command or real support code is used in this simulation.