Nowadays, it's increasingly common to log into an app with a single click using accounts like Microsoft or Google. Fast, convenient… and, in some cases, risky. What many people don’t realize is that by accepting certain permissions without a second thought, they could be handing over the keys to their information to an attacker. There's no need to steal a password — it's enough to trick the user into authorizing something that seems harmless.
Recently, a concerning campaign has been detected targeting employees of organizations linked to Ukraine and human rights advocacy. The attackers, operating out of Russia, pose as European officials and contact their targets through platforms such as WhatsApp and Signal. Their goal: to deceive victims into giving up Microsoft authorization codes or clicking malicious links that capture their credentials and temporary access tokens.
This forms the basis of a technique that is becoming increasingly common in the cybercriminal arsenal: the abuse of legitimate OAuth 2.0 authentication flows.
How Did the Attack Start?
It all began with a simple message on Signal or WhatsApp. According to researchers, in at least one case, that initial contact came from a Ukrainian government account that had already been compromised. In other words, the attackers were using real identities to appear more credible and gain their victims’ trust from the very first moment.
Email Sent to Targets (Source: Volexity)
The attackers pose as Ukrainian diplomats or European officials, reaching out to their victims with highly persuasive invitations to join private video calls on topics related to Ukraine.
Once they’ve captured the target’s attention and established a level of trust, they send a phishing link disguised as access to the video call. In reality, the link is a trap designed to steal access permissions to the victim’s Microsoft account.
In some cases, UTA0352 also sends a PDF file containing supposed instructions for joining the meeting. Inside the document, there is a link that actually leads to a malicious page designed to prompt the victim to sign in using their Microsoft account—taking advantage of OAuth flows commonly used by apps connected to Microsoft 365.
If the person falls for the trick and enters their credentials, they are redirected to what appears to be a browser-based version of Visual Studio Code, hosted at insiders.vscode.dev. According to researchers, this page is set up to capture Microsoft 365 login parameters, and the first thing the user sees is a dialog box that looks completely legitimate.
The attacker uses social engineering to convince the victim to send them a code, claiming it’s required to join the meeting. Since everything seems like a normal part of the process, it's easy to fall for the trick.
The problem is, that code is far from harmless—it’s a valid authorization code that’s good for 60 days. The attacker can use it to obtain an access token with all the permissions the user normally has. In other words, full access to their account.
A critical detail is that this code also appears in the browser’s address bar, making it easy to copy and share. All indications suggest that the web-based version of Visual Studio Code was intentionally configured to expose the code this way. On most platforms, users would typically just see a blank page with no useful information visible.
The researchers even created a diagram outlining how the attack works, showing how a custom app that mimics Visual Studio Code is used to facilitate the entire operation.
Full Attack Flow
Read more: What is Phishing? Protect Yourself from Digital Deception
Step-by-Step Deception: From Message to Full Account Takeover
A Familiar Tactic, Evolving Over Time
Researchers found that this type of attack isn’t entirely new. Earlier versions were seen using the older AzureAD v1.0 format instead of the newer v2.0 OAuth flow. The main difference lay in the parameters added to the URL, which were used to deceive users more effectively.
A more recent campaign, launched in April and attributed to a different group named UTA0355, followed a very similar pattern to UTA0352. This time, the initial contact came from a compromised Ukrainian government email account, lending even more legitimacy to the attacker’s message.
From OAuth Code Theft to Device Registration
In this case, the attacker used a stolen OAuth authorization code to register a new device in the victim’s Microsoft Entra account (formerly known as Azure Active Directory). But that wasn’t the end of the story. To complete the intrusion, they also needed the victim to approve a two-factor authentication (2FA) request—and once again turned to social engineering.
How did they do it? The attacker told the victim that the 2FA code was required to access a supposed SharePoint instance tied to a conference—a convincing scenario, especially for someone not paying close attention.
Persistent Access Without Detection
With that final step, the attackers not only obtained a token to read emails and access sensitive data—they also successfully registered a new device, allowing them to maintain long-term access without raising alarms. According to logs reviewed by researchers:
-
The device registration occurred immediately after interaction with the attacker.
-
By the next day, the attacker was already accessing the victim’s email.
-
By then, everything was set up so the victim would unknowingly approve the 2FA request.
How to Stay Protected
Security experts recommend the following mitigation strategies:
-
Configure alerts to detect sign-ins using the client_id associated with Visual Studio Code.
-
Block domains such as:
-
insiders.vscode.dev -
vscode-redirect.azurewebsites.net
-
-
Apply conditional access policies to restrict login access to authorized devices only.
Because yes—sometimes, a single code or an unthinking approval is all it takes to open the door to someone who shouldn’t be there.
