Link Laundering & Device-Code Deception

CyberShell Research Team

Contributor context

This article was prepared by the CyberShell Research Team, based on a live phishing campaign our team investigated in real time.

Travis Barlow

Subject matter expert

Deirdre Hennigar

Technical analysis, subject matter expert

Overview

This week we observed a few interesting phishing campaigns targeted toward several of our customers. One customer contact reported the email variants they had received that slipped through the Windows Defender protections. That head start is the whole point of a positive reporting culture — and it gave us the opening to go looking at the infrastructure behind the incidents.

The emails: real senders, priority targets

These emails did not come from throwaway Gmail accounts or clumsy look-alike domains. They came from the legitimate, authenticated mailboxes of real Canadian small businesses, an interior-design firm and a furniture retailer, whose accounts had themselves been compromised and pressed into service. The mail was dressed as an automated billing / document notification, complete with realistic campaign and tracking parameters, so it read as ordinary business-to-business correspondence.

Laundering the link through trusted domains

Rather than pointing at attacker infrastructure directly, where a URL reputation engine would flag it, the click was routed through a chain of domains no filter wants to block outright:

• First a google.com/url?q= open redirect, so the visible link is a Google address.
• Then a trackingservice.monday.com/tracker/link redirect, a legitimate marketing email-tracking service abused as a second hop.
• Only then a jump to the attacker's own redirector on leads.marke-ter[.]online.

Some variants added a meet.google.com/linkredirect hop as well.

The Monday.com tracking link carried a JSON Web Token, the service's own way of encoding to where it should redirect. Decoding it, which requires no secret because the payload is only base64-encoded, handed us the destination directly: an originalUrl of https://leads.marke-ter[.]online/hkiel/hpper/ and a per-recipient emailId.

The handoff: a redirector that knows who you are

The destination on leads.marke-ter[.]online was not the fake login itself. It was a thin redirector, sitting in an exposed open directory alongside sibling campaign folders. Its entire job was a few lines of JavaScript: read the victim's email address from the URL fragment, base64-decode it, and forward the browser to the credential page with that address pre-loaded.

This is a small touch with a big payoff. By the time the victim sees a login screen, their own email address is already filled in. The page looks less like a form to be suspicious of and more like a session that simply timed out.

The fake sign-in, and where the passwords went

The credential pages were textbook fake Microsoft 365 sign-in screens, served from domains like vortix[.]vu and infiflextechnologiesewppvtltd[.]vu, each with the target address pre-populated in the "Enter password" field. (Below is an example of what that looks like, using our "info@cybershell.ca" as a stand-in for a redacted customer email address).

Reading the page source told us where a submitted password would go. The form quietly posts the email and password to myfitnessapp.marketluxe[.]click/DoYoga-v2/form-loaded.php, hidden inside an unrelated "fitness app" domain (starring a lorem ipsum template). A companion reciever.php handler and a hardcoded drop address rounded out the collection kit. The misspellings, "Verifing" and "reciever," are a small reminder that the people running this are operators, not perfectionists.

The kit itself is more capable than a static form. Its behaviour is driven by an encoded configuration that maps out not just username and password fields but sections for verification codes, SMS one-time passcodes, and app-based approval prompts. In other words, it is built to relay and capture a second factor in real time, the hallmark of an adversary-in-the-middle kit, and it ships with a debugger trap to slow down anyone inspecting it.

A second lure, and a nastier one: device-code phishing

While we were tracing the original fake-login chain, the same line of investigation surfaced a second Microsoft-themed lure using a fundamentally different, and more dangerous, technique. It opened with a fake Cloudflare "Verify you are human" gate, complete with reassuring "secure browsing mode" text, then presented a page claiming the victim's organization required a password reset. To proceed, the page told the user to copy a short code and paste it into a Microsoft sign-in screen.

Here's the trick - that code was a genuine Microsoft device authorization code. When the victim pastes it into the real login.microsoftonline.com device-login page and authenticates, they are not signing in to their own device. They are approving the attacker's device, requesting access as the Microsoft Authentication Broker, from a location the flow itself reported as the United States in this case. There is no fake password page to detect, no look-alike domain to flag. The victim authenticates on Microsoft's own genuine page, and the attacker walks away with tokens.

This is why device-code phishing matters to leadership specifically: it defeats the mental model that "the URL was real, so the login was safe," and because it issues legitimate tokens, it can slip past MFA that relies on approvals or codes. The tell for a user is simple and worth teaching: Microsoft never asks you to paste a code you were given by a website into a sign-in screen. That instruction, by itself, is the attack!

What to do about it

The controls that actually blunt this campaign are not about spotting a clever link.

• Move to phishing-resistant MFA. FIDO2 security keys and passkeys defeat both AiTM credential relay and device-code approval, because there is no code or push for an attacker to capture or reuse.
• Restrict authentication flows you do not need. If your organization does not rely on device-code sign-in, block it with a Conditional Access authentication-flows policy. It is a rarely used feature and a commonly abused one.
• Watch tokens, not just logins. Device-code phishing issues real tokens, so hunt for the aftermath: new device registrations, sign-ins from unexpected locations, and refresh-token use that does not match the user.
• Distrust the link even when the domain is famous. google.com/url, tracking redirects, and aka.ms shorteners can all forward to anywhere. Reputation of the first hop says nothing about the last.
• Verify money-and-document requests out of band. A real, compromised partner is still a compromised partner. Confirm invoices, settlements, and signature requests through a known phone number or contact, not the email thread.
• Make reporting one click, and celebrate it. The single most effective control in this incident was a person who reported the message. That is early warning you cannot buy.

Indicators of compromise

Sources

• Microsoft Threat IntelligenceStorm-2372 conducts device code phishing campaign
• Microsoft LearnAuthentication flows as a condition in Conditional Access policy
• MITRE ATT&CKPhishing: Spearphishing Link (T1566.002)