Email bombing creates the crisis. Fake IT support arrives with the fix.

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.

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.

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.

Secure the entire chain, not just the inbox.