When an Attacker Moves the Conversation to Another Channel

Moving a support conversation to a call or another tool does not verify the sender. Check who is involved, where the conversation is going, and what access they want.

A phone receiver, a sealed envelope and a dark smartphone aligned along three perpendicular edges of a desk.

Does moving a conversation to another channel verify the person?

No. A second channel chosen by the same unverified requester does not independently establish identity. Verify the person, destination, and requested action through an established route before continuing.

When a support conversation moves from email to a call or remote-support tool, keep track of who verified the person and what work was authorized. The new channel does not supply those answers.

A short handoff record should identify the confirmed person, destination, and requested permission, especially when the next step asks for more access.

Two ways the conversation moves

In its May 2024 report, Microsoft described Storm-1811 contacting users by phone while impersonating support, including after email flooding. The June update documented Teams messages and calls leading into Quick Assist misuse. This is a historical observation of a support-to-device-access sequence. Microsoft Threat Intelligence: Storm-1811

A separate FBI warning in May 2025 described messages impersonating senior US officials. Actors used text and AI-generated voice messages to build rapport, including malicious links presented as a move to another messaging platform. The FBI advised checking new contact information through a previously confirmed platform or trusted source. FBI: malicious messaging campaign

In both cases, the defensive question is whether an independent identity check survives the move.

A second channel is not automatically independent

Suppose an unfamiliar sender writes, “Call me at this number to confirm.” Calling that number creates another conversation, but the original sender selected the destination. That alone cannot establish a relationship between the number and the identity being claimed.

The source of the contact details matters, as our callback contact-source guide explains. The same check applies beyond recovery calls. A new messaging account, meeting link, or support connection can also be introduced by the person whose authority remains unresolved.

For a business workflow, write down three separate questions: Is this the person they claim to be? Is this the approved destination for the interaction? Is the requested action authorized? A positive answer to one should not silently fill in the others. A known colleague can request an action outside their authority; an approved tool can connect an unverified participant.

Verify the handoff

  • Requester

    Proposes a new channel or permission. Check identity and task.

  • Independent route

    Use an established source. The request must not supply its own verification destination.

  • If unresolved

    Keep the action pending and name an escalation owner.

  • If confirmed

    Permit the named action only. Check again if scope changes.

The last two outcomes are alternatives based on verification.

A channel change triggers a check of identity, destination, and task. An unresolved check keeps the requested action pending. Open full-size diagram.

Watch for a change in the requested action

The transition worth recording is not merely email to phone. It might be conversation to authentication, conversation to screen sharing, or conversation to an account change. Those transitions change what the recipient is being asked to permit.

Microsoft’s Storm-1811 report describes screen-sharing approval and a subsequent control request as separate steps. Our remote-support article covers those permissions in detail. For this review, use that distinction to ask whether the employee rechecked the task when the requested permission changed. Microsoft: Quick Assist approval sequence

An assessment can stop at that decision. It does not need to grant control, collect credentials, or perform a real account change to establish whether the participant followed the agreed verification procedure. If technical actions are included, define their scope and evidence separately.

Keep the decision attached to the conversation

In the support ticket, identify who proposed the new channel, how the assignment was independently checked, and what permission was requested. Retain the last observed action and name the owner who must resolve anything still pending. Use evidence references rather than secrets or unnecessary personal details.

“Escalated” is incomplete unless the next team knows where the request went and what must be established before it resumes. Our two directions of help-desk impersonation explains how the employee and support desk can each receive an impersonation request.

Find the check that failed

Verification through a number supplied by an unverified caller is a contact-source problem. A confirmed contractor requesting work outside the assigned ticket is a task-authorization problem. Permission to view a screen followed by an unapproved control request is a scope change. Reporting all three as “verification failed” hides the correction each needs.

The service owner should make assignments verifiable, provide an independent contact route, and resolve scope changes. That process must also let legitimate contractors obtain confirmation; holding every request indefinitely is not a workable support service.

Give people one sentence they can use

A practical response is: “I can continue through our established support route once the person and requested task are confirmed.” The organization should provide that route and an exception owner for cases where it is unavailable.

Test what happens when the conversation moves.

Test whether verification holds when a support conversation moves to a call or another tool. Agree on the transition, requested permission, and stopping point.