Fake IT Support Calls: How Phishing Can Bypass MFA

On October 28, 2026, the Canadian Centre for Cyber Security published alert AL26-028 about an ongoing fake-help-desk campaign targeting Canadian organizations, including legal and financial firms. Callers impersonate internal IT staff and send employees to fraudulent sign-in pages.

The date marks the alert’s publication, not the start of the attacks. This article explains the warning and gives employees and small teams a practical response checklist. Facts checked on October 30, 2026.

The trap starts with a plausible request

Imagine this fictional call: “Hello, this is IT. Your account migration is overdue. Open the link I’m sending so we can finish before your next meeting.” You are busy, the caller sounds helpful, and the page looks familiar. The request moves you from a conversation into a sign-in you did not initiate.

This is voice phishing, or vishing. The Cyber Centre’s vishing guidance explains how impersonation, urgency and spoofed caller IDs create trust. A familiar name or displayed number is not independent verification.

Why some MFA checks can still be relayed

Google Threat Intelligence’s May 15 analysis of related help-desk impersonation describes a real-time relay: a lookalike page captures a password, submits it to the real service and asks the person to complete the resulting MFA challenge. A relayed code or approval can let the attacker authenticate. A complex password does not prevent someone from submitting it to the wrong page.

Keep MFA enabled. It still adds protection, but different methods resist different attacks. The Cyber Centre’s MFA guidance distinguishes push fatigue, token theft and interception, and recommends phishing-resistant methods. Number matching can help with push fatigue; it does not turn every approval into phishing-resistant authentication.

Pause and verify through a known channel

• End an unexpected call requesting a password change, MFA reset or new authenticator.
• Open your existing support bookmark or use the help desk contact from your internal directory. Avoid the caller’s link, supplied phone number and caller-ID callback button.
• Ask your verified support team whether the request is genuine before continuing.
• Do not disclose a password, one-time code or recovery code to the caller, or approve a sign-in you did not initiate and verify.

A useful reply is: “I’ll contact support through our usual channel and check the request there.” Your verification should work even if the caller disconnects. The goal is a repeatable routine, rather than guessing whether a voice sounds trustworthy.

A passkey pretext is not a broken passkey

The October alert includes urgent passkey enrolment among the callers’ pretexts. That does not show that passkey cryptography was defeated. FIDO explains that passkeys are tied to the service they were created for, helping resist lookalike-site phishing. Account recovery and enrolment still need protection: an attacker may try to persuade you to authorize an unwanted change.

For the differences between a password, a security key and a passkey, see our passkeys and passwords guide. Do not switch off an existing protection because an unsolicited caller claims it is blocking a migration.

If you have already entered credentials

Stop interacting with the page and notify your verified IT or security team immediately. Tell them which account was involved, when it happened and whether you entered a password, supplied a code or approved a request. Do not send them the actual password or code.

The October alert’s response guidance calls for revoking active sessions and tokens, resetting credentials, removing unauthorized MFA methods or devices, and reviewing account activity. A password reset alone may leave other access paths. Let the account administrator coordinate these actions for a workplace account.

Keep the message, page address and time of the call for the investigation without reopening the suspicious link. The Cyber Centre’s incident-response guidance emphasizes documenting events, assigning responsibilities and having an alternate contact channel. Reporting promptly gives the team a chance to contain the incident.

A short checklist for small teams

Google’s August 6 follow-up analysis recommends phishing-resistant authentication and managed-device access controls. Pair those technical controls with a written process for account recovery and new-device enrolment.

Make the reporting route easy to find before a problem occurs. Add a verified help desk contact and a short unexpected-call procedure to your team password policy. Practise the scenario using invented details, without collecting employees’ real passwords or codes.