Email bombing creates the crisis. Fake IT support arrives with the fix.
An inbox flood makes the employee want help. Attackers exploit that moment by impersonating IT and offering remote support.
Email bombing can manufacture the support emergency that makes a fake IT contact feel expected.
One attack can move across three channels
Zscaler ThreatLabz describes a campaign in which the initial compromise likely starts with spam bombing a victim's inbox. The attacker then contacts the employee through Microsoft Teams, poses as IT or helpdesk staff, and offers to solve the problem through a Quick Assist remote-support session.
Once the employee grants access, the attacker can move from a convincing support conversation to activity on the endpoint. The inbox flood, Teams contact, and remote session are not separate events. They form one attack chain.
The attacker manufactures both the crisis and its apparent solution. The flood gives fake IT a reason to appear and gives the employee a reason to accept help quickly.
October update: the support pretext is repeatable
Arctic Wolf's October 26 research examines more than 400 incidents involving external Teams chat abuse. That is not a count of confirmed compromises. In many cases, customers reported an inbox flood before or alongside the fake support contact. Teams voice calls then helped persuade employees to allow remote access.
Customer-reported attack chains reached payload execution in under 15 minutes after engagement. This timing is not a universal outcome. The report describes recurring behavior across incidents, not a newly discovered Teams vulnerability or proof that every case belongs to one actor.
The operational lesson is to treat the flood and the offer of help as one possible security event. An employee urgently seeking relief should not have to decide whether the apparent helper sounds convincing enough.
Restrict the tool. Verify the person.
Security teams should treat an unusual inbox flood as a security event, restrict Quick Assist and other remote-support tools, limit untrusted external collaboration, and monitor suspicious endpoint activity.
Arctic Wolf also recommends independent verification for remote-access requests. For the support team, make the response explicit: report the inbox flood through the established channel, verify the person offering help independently, and allow remote access only through an approved tool and authorized process. Verification is not permission to bypass the remote-support policy.
Those controls make the attack harder. They do not answer the employee's question: How do I know this is really IT?
An attacker can change the collaboration channel, the pretext, or the remote tool. A familiar display name, knowledge of the inbox problem, or a legitimate support application may make the request appear credible. None proves who is on the other side.
Before remote support begins, the employee should open a known, organization-controlled support or verification destination, not a link supplied by the person claiming to be IT. There, the employee should be able to confirm a current, short-lived request associated with an authorized support representative and the interaction being proposed. If no verified request exists, the employee stops and contacts support through an established channel.
Caller verification has to work both ways
Most helpdesk verification discussions focus on whether the support agent can verify the employee before a reset or recovery action. This attack requires the reverse direction as well: the employee needs to verify the person claiming to be IT before granting remote access or following a sensitive instruction.
That is the model behind Fctr's two-way caller verification. Helpdesk agents verify employees, and employees verify callers claiming to be IT or support, using organization-managed identity evidence.
The verification is bound to the active interaction. It does not itself authorize a remote session, account change, or other action.
Email security should detect the flood. Collaboration and endpoint controls should constrain what follows. Caller verification addresses the trust decision between them: whether the person offering help is actually authorized to do so.
Use our practical guide to IT caller verification to test whether employees can find the trusted destination, recognize a completed check, and get legitimate help when verification fails.
Secure the entire chain, not just the inbox.