Account takeovers via device code phishing, exploiting the OAuth 2.0 Device Authorization Grant process, have seen a staggering increase of over 37 times this year.

In this type of attack, the attacker initiates a device authorization request with a service and obtains a unique code, which they then deceive the victim into using.

The victim is tricked into entering the code on the real login page, unintentionally granting the attacker’s device authorized access to their account using legitimate access and refresh tokens.

This process was initially created to facilitate connections for devices lacking easy input methods, such as IoT gadgets, printers, media streaming devices, and smart TVs.

The device code phishing strategy was first identified in 2020, but its malicious use was noted a few years later and has been employed by both government-backed and financially motivated attackers [1, 2, 3, 4].

Researchers at Push Security have observed a significant rise in these attacks, cautioning that they are now commonly used by cybercriminals.

Recently, the security firm Sekoia released research on the EvilTokens phishing-as-a-service (PhaaS) platform. The researchers highlight it as a prominent example of a phishing toolkit that makes device code phishing more accessible to less-skilled cybercriminals.

Push concurs EvilTokens is a large factor in the technique’s widened adoption. But also adds that similar platforms exist on the market — those platform may gain market-share if law-enforcement disrupts EvilTokens:

Push Security also posted a video illustrating how the DOCUPOLL kit functions. The attacker spoofs DocuSign branding and uses a fictitious contract as bait, prompting the victim to log into the Microsoft Office program.

In total, there are at least 11 phishing kits available to cybercriminals offering this type of attack, all using believable SaaS-themed decoys, anti-bot measures and cloud platforms for infrastructure and hosting.

To defend against device-code phishing attacks, Push Security suggests users disable the feature through conditional access policies on accounts when not needed.

They also recommend monitoring logs for unexpected device code authentication events, abnormal IP addresses, and suspicious sessions.