CyberVolk is a pro-Russia hacktivist persona we first documented in late 2024, tracking its use of multiple ransomware tools to conduct attacks aligned with Russian government interests. After seemingly lying dormant for most of 2025 due to Telegram enforcement actions, the group returned in August with a new RaaS offering called VolkLocker (aka CyberVolk 2.x).

In this post, we examine the functionality of VolkLocker, including its Telegram-based automation, encryption mechanisms, and affiliate features. Our analysis reveals an operation struggling with the challenges of expansion: taking one step forward with sophisticated Telegram automation, and one step backward with payloads that retain test artifacts enabling victim self-recovery.

Technical Details

VolkLocker payloads are written in Golang, with versions supporting both Linux and Windows. Base builds are shipped without obfuscation, and RaaS operators are encouraged to use UPX for packing rather than being offered native crypting or packing features as is common with many other RaaS offerings.

Operators building new VolkLocker payloads must provide a bitcoin address, Telegram bot token ID, Telegram chat ID, encryption deadline, desired file extension, and self-destruct options.

Upon launch, the ransomware checks its execution context and attempts privilege escalation if needed. Escalation uses the “ms-settings” UAC bypass technique (T1548.002), hijacking the HKCU\Software\Classes\ms-settings\shell\open\command registry key to execute with elevated privileges.

The malware performs environmental discovery and system enumeration, including process enumeration for virtual environment detection and hardware-based identification.

VolkLocker checks the local MAC address against known virtualization vendor prefixes. Registry locations associated with VirtualBox and VMware are also queried.

Once initialized, the ransomware enumerates all available drives (A: through Z:) and determines which files to encrypt based on exclusion lists for specific paths and extensions configured in the VolkLocker code.

Encryption Mechanism

VolkLocker uses AES-256 in GCM mode (Galois/Counter Mode) for file encryption. When the ransomware identifies a target file, it initializes an encryption engine using a 32-byte master key decoded from a 64-character hex string embedded in the binary.

For each file, the malware generates a random 12-byte nonce for the initialization vector using Golang’s crypto/rand package. The file is encrypted using the GCM Seal operation, which prepends the 12-byte nonce to the ciphertext and appends a 16-byte authentication tag. The original file is marked for deletion, and the encrypted file receives a custom extension (e.g., .locked, .cvolk).

Critical Design Flaw | Plaintext Key Backup

VolkLocker does not generate encryption keys dynamically. Instead, master keys are hardcoded as hex strings within the binaries. The same master key encrypts all files on a victim system.

Critically, this master key is also written to a plaintext file in the %TEMP% folder, creating a trivial decryption pathway for victims who discover it.

This design flaw exists in the backupMasterKey() function, which executes during initialization and performs the following:

• Constructs a file path at %TEMP%\system_backup.key (typically C:\Users\\AppData\Local\Temp\system_backup.key)
• Writes a plaintext file containing the victim’s unique identifier, the complete master encryption key, and the attacker’s Bitcoin address
• Applies Windows Hidden and System file attributes to obscure the file from casual directory listings
• The file format is:

  User: CV<16 hex characters>
  Key: <64 hex characters - THE MASTER KEY>
  BTC: <attacker's bitcoin address>
  

Since the ransomware never deletes this backup key file, victims could attempt file recovery by extracting the necessary values from the file.

The plaintext key backup likely represents a test artifact inadvertently shipped in production builds. CyberVolk operators may be unaware that affiliates are deploying builds with the backupMasterKey() function still embedded. Given that VolkLocker is a relatively new service, the presence of what appears to be debug functionality in live deployments suggests that the operation is struggling to maintain quality control while aggressively recruiting lesser-skilled affiliates.

System Lockdown & Persistence Features

VolkLocker modifies multiple registry keys to inhibit system recovery and analysis:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender" /v DisableAntiSpyware /t REG_DWORD /d 1 /f

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System" /v DisableTaskMgr /t REG_DWORD /d 1 /f

reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System" /v DisableTaskMgr /t REG_DWORD /d 1 /f

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System" /v DisableRegistryTools /t REG_DWORD /d 1 /f

reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System" /v DisableRegistryTools /t REG_DWORD /d 1 /f

reg add "HKCU\Software\Policies\Microsoft\Windows\System" /v DisableCMD /t REG_DWORD /d 2 /f

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\System" /v DisableCMD /t REG_DWORD /d 2 /f

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" /v NoRun /t REG_DWORD /d 1 /f

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" /v NoClose /t REG_DWORD /d 1 /f

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" /v NoDrives /t REG_DWORD /d 4 /f

In addition, Windows Defender is targeted for termination via PowerShell:

powershell -Command "Set-MpPreference -DisableRealtimeMonitoring $true"
sc config WinDefend start= disabled
net stop WinDefend /y

The malware also terminates processes associated with common analysis tools via taskkill.exe:

• processhacker.exe
• procexp.exe
• procexp64.exe
• taskmgr.exe

VolkLocker creates multiple identical copies of itself in various system locations to establish persistence:

    %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\cvolk.exe
    %PUBLIC%\Documents\svchost.exe
    %SYSTEMDRIVE%\ProgramData\Microsoft\Network\wlanext.exe
    %TEMP%\WindowsUpdate.exe

Ransom Note and Countdown Timer

VolkLocker’s ransom note is a dynamic HTML application. The file cybervolk_ransom.html is written to %TEMP% and launched both after encryption completes and upon system startup. The ransom note displays a countdown timer with a default duration of 48 hours. The duration of the timer can be configured by the RaaS operators.

The JavaScript-based countdown timer is purely cosmetic. When it reaches zero, the triggerDestruction() function displays a shake animation and the message “ SYSTEM DESTROYED .”

However, a separate enforcement timer operates independently of the browser-based display.

This enforcement timer is synchronized with the system clock using Golang’s time.After() function. When it expires, it calls the SystemCorruptor() and DestroySystem() functions. The same destructive routine triggers if an incorrect decryption key is provided more than the configured maxAttempts value. The default is three times.

File & Backup Destruction Mechanism

During system destruction, VolkLocker deletes the following folders from the user profile:

• Documents
• Desktop
• Downloads
• Pictures

The malware also deletes Volume Shadow Copies:

vssadmin delete shadows /all /quiet

Finally, VolkLocker triggers a BSOD (Blue Screen of Death) after a 10-second delay by calling NtRaiseHardError() with a specific status code.

Telegram Integration

All aspects of the CyberVolk RaaS are managed through Telegram. Prospective customers and operational queries are directed to the main bot (CyberVolk_Kbot).

VolkLocker payloads include built-in Telegram automation for command and control. This aligns with CyberVolk’s operational model, where all communication, purchasing, and support occur through Telegram, a model the actors see as a “market differentiator”.

The default Telegram C2 supports the following commands:

The Telegram C2 is customizable. Some CyberVolk operators have published examples that include additional capabilities, such as keylogging control.

The telegramReporter() function alerts operators upon new infections, similar to Telegram-enabled infostealers. When a host is infected, basic system information and a screenshot are sent to the configured Telegram chat.

Expanded Services and Pricing

CyberVolk has expanded beyond ransomware. In November 2025, operators began advertising standalone RAT and keylogger tools, with the following advertised pricing model:

• RaaS (single OS): $800-$1,100 USD
• RaaS (Linux + Windows): $1,600-$2,200 USD
• Standalone RAT or Keylogger: $500 USD each

Intelligence suggests bundle discounts are available for customers purchasing multiple services.

Conclusion

Despite repeated Telegram account bans and channel removals throughout 2025, CyberVolk has reestablished its operations and expanded its service offerings.

However, storing master encryption keys in plaintext is a significant design blunder that undermines the ransomware’s effectiveness, allowing victims to recover files without acceding to the threat actor’s ransom demand.

Nevertheless, defenders should see CyberVolk’s adoption of Telegram-based automation as a reflection of broader trends among politically-motivated threat actors. These groups continue to lower barriers for ransomware deployment while operating on platforms that provide convenient infrastructure for criminal services.

The SentinelOne Singularity Endpoint Platform currently detects and prevents malicious behaviors and artifacts associated with CyberVolk Ransomware attacks.

Indicators of Compromise

CyberVolk (VolkLocker 2025) Linux
0948e75c94046f0893844e3b891556ea48188608

CyberVolk (VolkLocker 2025) Windows
dcd859e5b14657b733dfb0c22272b82623466321

Bitcoin Address
bc1qujgdzl0v82gh9pvmg3ftgnknl336ku26nnp0vy (CyberVolk)

Telegram Bot Token
8368663132:AAHBfe3xYPtg1IMynKhQy1BRzuF5UZRZspw (CyberVolk)

KEY TAKEAWAYS

• Since early March 2025, Volexity has observed multiple Russian threat actors aggressively targeting individuals and organizations with ties to Ukraine and human rights.
• These recent attacks use a new technique aimed at abusing legitimate Microsoft OAuth 2.0 Authentication workflows.
• The attackers are impersonating officials from various European nations, and in one instance leveraged a compromised Ukrainian Government account.
• Both Signal and WhatsApp are used to contact targets, inviting them to join or register for private meetings with various national European political officials or for upcoming events.
• Some of the social engineering campaigns seek to fool victims into clicking links hosted on Microsoft 365 infrastructure
• The primary tactics observed involve the attacker requesting victim's supply Microsoft Authorization codes, which grant the attacker with account access to then join attacker-controlled devices to Entra ID (previously Azure AD), and to download emails and other account-related data.

Since early March 2025, Volexity has observed multiple suspected Russian threat actors conducting highly targeted social engineering operations aimed at gaining access to the Microsoft 365 (M365) accounts of targeted individuals. This activity comes on the heels of attacks Volexity reported on back in February 2025, where Russian threat actors were discovered targeting users and organizations through Device Code Authentication phishing.

Since that reporting, while there has been an observable drop in Russian threat actors leveraging that specific method, Volexity has observed them pivoting to different methods of attack that abuse other legitimate M365 OAuth authentication workflows. These recently observed attacks rely heavily on one-on-one interaction with a target, as the threat actor must both convince them to click a link and send back a Microsoft-generated code.

Volexity is currently tracking what is believed to be at least two Russian threat actors, which it tracks as UTA0352 and UTA0355, that are behind these attacks. It is plausible that there are overlaps between these threat actors and those Volexity previously reported as conducting Device Code Authentication phishing campaigns in January and February 2025. This blog post details the different techniques used by these threat actors and the commonalities between their campaigns, which can be summarized as follows:

• The attacker contacts the victim via a messaging application (Signal, WhatsApp) and invites them to join a video call to discuss the conflict in Ukraine.
• Once the victim has responded, the attacker sends an OAuth phishing URL that they claim is required to join the video call.
• The victim is asked to return the Microsoft-generated OAuth code back to the attacker.
• If the victim shares the OAuth code, the attacker is then able to generate an access token that ultimately allows access the victim’s M365 account.

Diplomatic Channels to Nowhere

In March 2025, Volexity learned that some of its customers' staff were receiving suspicious messages via Signal and WhatsApp. The targeted staff members worked at NGOs that support human rights and specifically have expertise and experience working on issues related to Ukraine. The messages claimed to be from European political officials and were themed around discussing matters involving Ukraine. In each observed instance, the call to action was to arrange a meeting between the target and a political official, or Ambassador, of the European country of which the sender claimed to represent.

If the target responded to messages, the conversation would quickly progress towards actually scheduling an agreed upon time for the meeting. However, perhaps in an attempt to not arouse suspicion, in some cases the "Ambassador" would not be immediately available, and the meeting would be scheduled for days later.

As the agreed meeting time approached, the purported European political official would make contact again and share instructions on how to join the meeting. These instructions typically came in the form of a document uploaded into the messaging platform. This "official" would then send a link for the target to click on in order to join the meeting. These shared URLs all pointed to the official login portal for M365 via login.microsoftonline.com.

It should come as no surprise that these were, in fact, phishing campaigns, and the supplied instructions involved sending a code back to the attacker. However, unlike the previously observed attacks, these URLs were not associated with Device Code Authentication workflows. Instead, these URLs pointed to other Microsoft OAuth 2.0 authentication workflows associated with various legitimate first-party Microsoft applications. Volexity attributes the initial series of attacks observed to a suspect Russian threat actor it tracks as UTA0352.

In these campaigns, clicking the link alone would not be enough for the account to be compromised. The code would need to be supplied back to the attacker. The supplied links would redirect to official Microsoft URLs and, in the process, generate a Microsoft Authorization Token that would then appear as part of the URI, and in some cases, within the body of the redirect page. This code could then be used to generate an Access Token, which would grant the holder with access to the account for which it was generated. In multiple observed instances, the attacker would request the code be emailed or sent back via WhatsApp or Signal.

Volexity observed UTA0352 impersonating individuals representing the following countries and affiliations:

• Mission of Ukraine to the European Union
• Permanent Delegation of the Republic of Bulgaria to NATO
• Permanent Representation of Romania to the European Union

Based on other observations, Volexity believes UTA0352 also likely impersonated officials from Poland as well, but Volexity did not observe this directly. The images below show examples of initial outreach messages sent by UTA0352 impersonating various identities on Signal (left) and WhatsApp (right).

Phishing via Visual Studio Code

In mid-March 2025, one of Volexity's customers was contacted by UTA0352 claiming to be a government official from Romania. They attempted to set up a meeting with their Ambassador. Once the user engaged, the attacker sent a message explaining the need to set up a meeting on their web-based “Extended Verification System (EVS)” hosted on their secure servers. This message was accompanied by a PDF file with instructions on what to expect and how to join, after which a maliciously crafted URL was sent to the target.

The image below shows the two-page PDF document purporting to be from the Romanian Ministry of Foreign Affairs.

The URL shared by UTA0352 had the following format:

https://login.microsoftonline[.]com/organizations/oauth2/v2.0/authorize?state=https://mae.gov[.]ro/[REMOVED]&client_id=aebc6443-996d-45c2-90f0-388ff96faa56&scope=https://graph.microsoft.com/.default&response_type=code&redirect_uri=https://insiders.vscode.dev/redirect&login_hint=<EMAIL HERE>

This URL format is used by M365 to log in to both Microsoft-native/first-party applications and third-party applications using M365’s OAuth workflows. The key parameters of the URL are described in the Microsoft OAuth documentation; for convenience, they are briefly described below:

If the user is already logged in with the account specified in the login_hint parameter, they will be seamlessly redirected. If the user is not already authenticated, they will be prompted to log in to their M365 account. Once authenticated, the user is redirected to an in-browser version of Visual Studio Code, hosted at insiders.vscode.dev. The URL redirects the user to the /redirect page, which is designed to receive login parameters from M365, including OAuth. When the user is redirected to this page, they are presented with the following dialog:

The code displayed via the Visual Studio Code dialog is an OAuth 2.0 authorization code that can be used for up to 60 days. This code can be submitted to Microsoft’s OAuth workflow for an access token, which can then be used to access the M365 Graph API. Since the original request asked for the user’s default access rights, anyone with access to this authorization code also has access to all resources normally available to the user. It should be noted that this code also appeared as part of the URI in the address bar. The Visual Studio Code appears to have been set up to make it easier to extract and share this code, whereas most other instances would simply lead to blank pages.

The message shown under the main header uses the state value from the prior request, which is commonly used to indicate where the request to authenticate came from. However, as described in Microsoft's documentation, this value is arbitrary. It is up to the handling application (in this case, Visual Studio Code) to decide if and how to use this value. UTA0352 abused this to make it look like an authentication attempt to a Romanian government service. This is a theme repeated in other phishing attacks as an effort to make the links appear legitimate.

The diagram below shows the overall workflow followed by the attacker to target users leveraging the Visual Studio Code first-party application. The workflow varies slightly from other attacks observed later but is fairly similar overall.

Earlier Variations of Visual Studio Code Phishing

In addition to the phishing attack described above, Volexity also identified an older variation of a phishing campaign believed to have been employed by UTA0352. In this earlier campaign, the following URL format was used:

hxxps://login.microsoftonline[.]com/common/oauth2/authorize?redirect=https://zoom.us/j/<snip>&client_id=aebc6443-996d-45c2-90f0-388ff96faa56&resource=https://graph.microsoft.com&response_type=code&redirect_uri=https://vscode-redirect.azurewebsites.net&login_hint=<removed>&ui_locales=en-US&mkt=en-US&client-request-id=<removed>

The URL differs from the one previously described, in that it employs the format used by the AzureAD v1.0 specification, not v2.0 used in the initially observed campaign. The key differences between the URL parameters used are noted below:

The workflow the older campaign variation initiates is similar to the initially observed campaign. If a user is logged in, they are redirected to vscode-redirect.azurewebsites.net, which in turn redirects to a local IP address (127.0.0.1). When this happens, instead of yielding a user interface with the Authorization Code, the code is only available in the URL. The final URL is in the following format:

hxxp://127.0.0.1:9217/callback?code=1.ARsAIGLD9ki0FE63WmhS-KbgFENkvK5tmX[snipped]D&session_state=[uuid]

This yields a blank page when rendered in the user’s browser. The attacker must request that the user share the URL from their browser in order for the attacker to obtain the code.

UTA0355: Phishing via Compromised Ukrainian Government Account

Then, in early April 2025, Volexity identified another new Microsoft 365 OAuth phishing campaign. This time, the campaign started with an email from a legitimate, compromised Ukrainian Government email account, which was then followed by messages sent via Signal and WhatsApp. The emails and follow-up messages invited targets to join a video conference related to Ukraine's efforts "to investigate and prosecute atrocity crimes, as well as the country’s cooperation with international partners in this field.”

As with previous OAuth phishing techniques that Volexity has reported, the ultimate intention of this campaign is to use the legitimate Microsoft 365 authentication API to gain access to the victim’s email data. However, in this campaign, the attacker uses the stolen OAuth authorization code to register a new device to the victim’s Microsoft Entra ID (formerly Azure Active Directory) on a permanent basis. After registering the device in Entra ID, the attacker then needs to further socially engineer the target into approving a two-factor authentication request in order to gain access to the victim’s email.

While this campaign uses similar techniques to those employed by UTA0352, Volexity currently tracks these attacks separately and attributes this activity to a threat actor it has labeled UTA0355.

Multi-stage Social Engineering

Unlike the attacks that Volexity observed from UTA0352, this new phishing campaign started with an email that was sent to multiple targets. The email invited the targets to a video conference and included the event details. The email did not include any links or instructions, but it did solicit interest from the recipient on if they wished to attend. However, despite the initial outreach coming via email, Volexity found that UTA0355 quickly followed up with each recipient via Signal or WhatsApp, referencing the email that was sent, likely to add legitimacy to their messaging.

Volexity believes that UTA0355 only sent the email from the compromised Ukrainian Government account to individuals for whom it had out-of-band contact information. This was likely to facilitate real-time conversations to assist with social engineering efforts, and to keep information outside of email where it could more easily be discovered or later examined.

The initial email that was sent to various targets is shown in the image below.

Not long after this email was sent to various targets, the follow-up message from UTA0355 referencing the email was sent via Signal or WhatsApp; an example of which is shown below.

OAuth Phishing and the Device Registration Service

Like other OAuth phishing techniques, the one used in this campaign involved direct interaction with the victim to have them click a link and supply a code back to the attacker. This code is then sought by the attacker and used to obtain illicit access to M365 resources.

Victim Interaction

If the target responded to the message UTA0355 sent via Signal or WhatsApp, they would be sent an M365 login URL to click; the URL format is shown below:

https://login.microsoftonline.com/common/oauth2/authorize?url=https://teams.microsoft.com/[redacted]&client_id=29d9ed98-a469-4536-ade2-f981bc1d605e&resource=01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9&response_type=code&redirect_uri=https%3A%2F%2Flogin.microsoftonline.com%2FWebApp%2FCloudDomainJoin%2F8&amr_values=ngcmfa&login_hint=<email@address.here>

After the victim logged in via the shared Microsoft URL, they would be redirected to a new URL that contained an OAuth authorization code within the URL. The attacker included additional instructions indicating the victim should share the URL they see in their address bar after the redirect occurs. The URL generated by the victim’s browser, and subsequently returned to UTA0355, follows the format below:

https://login.microsoftonline.com/WebApp/CloudDomainJoin/8?code=[redacted]&session_state=[redacted]

By sharing this URL with the attacker, the victim would unknowingly hand over all the information required to authenticate as themselves. This is similar to other observed and suspected attack campaigns. And again, this does require the target to both click a link and send back a code or URL. However, the victim is only ever asked to interact with legitimate Microsoft 365 services, which users may inherently see as trustworthy. Additionally, it may not immediately appear obvious to a user that sharing data from their address bar, or from text displayed on a legitimate Microsoft webpage, would facilitate granting an attacker access to their M365 account.

UTA0355 OAuth Abuse

The URL the victim would share with the attacker includes a code parameter containing an OAuth authorization code, which would then be used to grant access tokens. Unlike similar previous campaigns, the resource requested in the initial login is not access to the Microsoft Graph API; instead, it is for the Device Registration Service. This service is used by Windows to join new devices to Entra ID. The attacker would use this access to join a new device named DESKTOP-[redacted] to the victim’s Entra ID. Volexity was able to use the ROADTools project to replicate these steps, and followed this guide to create a new token with full permissions for Microsoft Graph API access. This technique uses a flaw in the Entra ID API design to grant an access token with a greater level of access than that initially granted.

After the initial interaction had taken place, and UTA0355 had registered their device with the victim’s Microsoft Entra ID (Azure AD), Volexity observed an additional interaction with the victim. In this interaction, UTA0355 requested that the victim approve a two-factor authentication (2FA) request to “gain access to a SharePoint instance associated with the conference”. This was required to bypass additional security requirements, which were put in place by the victim’s organization, in order to gain access to their email.

Post-compromise Activity

Volexity assesses with high confidence that the attacker required the victim to approve a 2FA request to access email items. In logs reviewed by Volexity, initial device registration was successful shortly after interacting with the attacker. Access to email data occurring the following day, which was when UTA0355 had engineered a situation where their 2FA request would be approved. Once access was granted, logs showed the attacker downloaded the target’s email using a session tied to the newly registered device.

The login activity, email access, and device registration all took place using a client IP address belonging to a proxy network that was geolocated to where the victim was located.

Detecting Related Activity

To generally prevent or detect these attacks, Volexity recommends the following:

• Consider alerting on M365 login activity where the Visual Studio Code client_id value aebc6443-996d-45c2-90f0-388ff96faa5 is used in combination with a resourceDisplayName containing “Microsoft Graph”. Depending on your environment and the usage of Visual Studio Code, this may or may not be feasible, as legitimate users will also login using this client_id.
• Consider alerting on the following URL format (either embedded in email or proxy logs). Note that the parameters in the URL can appear in any order, and that the redirect_uri values must be set to insiders.vscode.dev/redirect or vscode-redirect.azurewebsites.net:
  

  https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?state=[any_url]&client_id=aebc6443-996d-45c2-90f0-388ff96faa56&scope=https://graph.microsoft.com/.default&response_type=code&login_hint=[email]&redirect_uri=https://insiders.vscode.dev/redirect

  https://login.microsoftonline[.]com/common/oauth2/authorize?redirect=[any_url]&client_id=aebc6443-996d-45c2-90f0-388ff96faa56&resource=https://graph.microsoft.com&response_type=code&redirect_uri=https://vscode-redirect.azurewebsites.net&login_hint=[email]&ui_locales=en-US&mkt=en-US&client-request-id=[removed]
  

• Evaluate the business impact associated with blocking access to the insiders.vscode[.]dev and vscode-redirect.azurewebsites.net hostnames and consider implementing such blocks.
• Educate users about the risks associated with new and unknown contacts established through secure messaging platforms. It is crucial that users understand the importance of verifying the identities of contacts that reach out via Signal, WhatsApp, or other secure messaging platforms. Verification should be done out-of-band instead of trusting information provided via unsolicited or unexpected outreach.
• Consider looking for newly registered devices, and correlate with registering IP addresses to look for low-reputation or proxy IP addresses appearing in the ClientIPAddress.
  • Be aware that ongoing access to the user’s email via the Microsoft Graph API will not contain an attacker IP address in the ClientIPAddress field; instead, it contains a Microsoft IP address. This behavior does not appear to be documented and is counterintuitive to security analysis.
  • While attacker activity cannot easily be tracked via the ClientIPAddress field, Volexity was able to track attacker activity based on the unique deviceId value associated with the device that was registered by the attacker.
  • The ClientAppID field for ongoing access may differ from the user’s typical email client, as it will use an AppID corresponding to one created by the attacker.
• Consider implementing conditional access policies that restrict access to organizational resources to only approved or managed devices. This can be effective at preventing device registration and unauthorized access to other resources such as email.
  • At the time of publication, Volexity is not aware of a way to block specific first-party Microsoft apps via conditional access policies. Conditional access can be used to block access to all services for non-compliant devices; however, this may prove challenging for organizations to implement in a short timeframe.
  • It should also be noted that Microsoft Teams was one of the resources Volexity also observed UTA0352 targeting. It is not likely reasonable or feasible for most organizations to block this, if it were even possible.

Conclusion

Motivated threat actors will continuously look for new ways to circumvent security controls and gain access to resources using new methods that are not well known to users or cyber defense teams. This latest series of attacks marks the second time since January 2025 that Russian threat actors have blitzed little-known techniques to obtain access to M365 resources. Volexity surmises that these attacks targeting NGOs, Think Tanks, and human rights defenders may be ramping up in order to capitalize on the current situation these individuals and organizations are facing in the form of budget cuts and reduced staffing.

Similar to the Device Code Authentication phishing campaigns that Volexity reported in February 2025, these recent campaigns benefit from all user interactions taking place on Microsoft’s official infrastructure; there is no attacker-hosted infrastructure used in these attacks. Similarly, these attacks do not involve malicious or attacker-controlled OAuth applications for which the user must explicitly grant access (and thus could easily be blocked by organizations). The use of Microsoft first-party applications that already have consent granted has proven to make prevention and detection of this technique rather difficult.

Organizations should train users to be highly vigilant when it comes to unsolicited contact, especially if it arrives via secure messaging apps and request that users click links or open attachments. Further, for this specific type of attack to be successful, the attacker must request that the user send back a URL or code from the link they clicked on. This tactic is not something users are typically trained to be aware of and should be added to an organization's users' security awareness training.

At this time, Volexity notes that NGOs, organizations related to human rights and providing aid and humanitarian assistance, and those with ties to Ukraine are likely the most at risk and potential targets of these campaigns. And while this threat activity is ongoing in limited targeted attacks, Volexity expects that this method of attack will continue and may become more widespread. Therefore, organizations should broadly warn users about this type of attack.

Finally, all messages attributed to UTA0352 and UTA0355 were themed around Ukraine, and targeted numerous individuals and organizations that have historically been targeted by Russian threat actors. Based on this, and the use of similar tactics observed in February 2025, Volexity assesses with medium confidence that both UTA0352 and UTA0355 are Russian threat actors. It is unclear if they are working in coordination or have overlaps with Volexity's previous reporting.

INVESTIGATIVE ASSISTANCE

 

If any organization or individual believes they may have been targeted by UTA0352, UTA0355, or in a similar attack, please feel free to reach out to Volexity via our contact form. We would be glad to assess any potential targeting and assist in determining if such an attack may have succeeded.

Acknowledgements

Volexity would like to thank its customers for their vigilance, cooperation, hard work, and dedication to defending human rights. Volexity would also like to thank the MIL.CERT-UA of the Ministry of Defence of Ukraine for their ongoing assistance and cooperation.

The post Phishing for Codes: Russian Threat Actors Target Microsoft 365 OAuth Workflows appeared first on Volexity.

Executive Summary

• SentinelLABS has observed a campaign targeting opposition activists in Belarus as well as Ukrainian military and government organizations.
• The campaign has been in preparation since July-August 2024 and entered the active phase in November-December 2024.
• Recent malware samples and command-and-control (C2) infrastructure activity indicate that the operation remains active in recent days.
• SentinelLABS assesses that this cluster of threat activity is an extension of the long-running Ghostwriter campaign identified in previous public reporting.

Ghostwriter | Background

Ghostwriter is a long-running campaign likely active since 2016 and subsequently described in various public reports throughout 2020 to 2024. The actor behind Ghostwriter campaigns is closely linked with Belarusian government espionage efforts, while most commonly reported under the APT names UNC1151 (Mandiant) or UAC-0057 (CERT-UA). Some public reports may use the term “Ghostwriter APT” interchangeably to refer to both the threat actor and its associated campaigns.

Previous research on the evolution of Ghostwriter noted how it operated successfully across a range of platforms, blending information manipulation with hacking to target a number of European countries. Reporting throughout 2022 to 2024 described activity in which malicious Excel documents were used to deliver PicassoLoader and Cobalt Strike payloads. Observed document lures were themed around issues pertaining to the Ukraine military and the likely targeting of the Ministry of Defense.

SentinelLABS has observed new activity with multiple weaponized Excel documents containing lures pertaining to the interests of the Ukraine government, the Ukraine military and domestic Belarusian opposition. While some of the TTPs we have observed overlap with previous reporting, others are new, including adaptations of previously observed payloads such as PicassoLoader.

Weaponized XLS 1 | “Political Prisoners in Minsk Courts”

SentinelLABS analyzed an attack that started with a Google Drive shared document landing in the target’s inbox. The email originated from an account using the name “Vladimir Nikiforech” (vladimir.nikiforeach@gmail[.]com). The email link pointed to a downloadable RAR archive, which according to the internal timestamps was created on 2025-01-14 00:47:54, containing a malicious Excel workbook (ebb30fd99c2e6cbae392c337df5876759e53730d) with the file name политзаключенные(по судам минска).xls (“Political prisoners (across courts of Minsk).xls”).

The title of the lure indicates an interesting shift in Ghostwriter targeting. Although attribution for the 2021 Ghostwriter campaign pointed to the Belarus state, this is the first time we have seen lures directly aimed at Belarus government opposition. The timing of the attack could have been motivated by the presidential election that took place shortly after on Jan 26, 2025.

The XLS document contains an obfuscated VBA macro which is activated when the document is opened and the user allows Office macros to run.

On execution, the macro writes a file to %Temp%\Realtek(r)Audio.dll.

The DLL file is loaded with the following command line invocation:

C:\Windows\System32\regsvr32.exe /u /s "C:\Temp\Realtek(r)Audio.dll”

This starts the standard Windows process regsvr32.exe, which calls the DllUnregisterServer function implemented inside the DLL; the function then loads and executes the .NET assembly described next.

Analysis of Dwnldr.dll shows that it is a DLL file with a .NET assembly embedded inside. The file is protected with ConfuserEx – a publicly available tool that helps to obfuscate .NET programs and observed in previous Ghostwriter campaigns.

The DLL file hosts a payload that appears to be a simplified variant of PicassoDownloader, a malware family also linked to Ghostwriter activity. The internal filename (Dwnldr.dll) was previously used by the Ghostwriter threat actor; however, this variant bears only high-level similarities to previous versions, with significant changes to the underlying code, possibly to make it a cheaper and more expendable tool.

As a part of application protection provided by the obfuscator, the Downloader creates a copy of itself in memory, and then modifies it. It does so by decrypting additional code of the assembly. It also uses a clever evasion technique, altering its own PE header in memory and breaking internal links to the .NET assembly. This makes it impossible for security products to parse it as a .NET module.

During code execution, after the protection layer passes control to core functionality, the Downloader writes a decoy Excel workbook file to %AppData%\Roaming\Microsoft\temp.xlsx and downloads additional file(s) from the Web.

The temp.xlsx decoy file (18151b3801bd716b5a33cfc85dbdc4ba84a00314) is immediately opened in Excel in an attempt to make the victim believe that it contains the original content of the политзаключенные (по судам минска).xls file.

The spreadsheet contains the names of people with criminal charges along with the names of prosecutors and judges: content that invites the reader to believe it could be leaked from a government source. However, the information was already in the public domain and can be found on the website of a proscribed Belarusian human rights organization, Spring96.

Once the decoy Excel file is opened, the Downloader attempts to fetch the next stage from the following URL:

https://everythingandthedog[.]shop/petsblog/2020/2/25/tips-for-taking-difficult-dogs-on-a-walk.jpg

We note that the .shop top level domain was also reported in other Ghostwriter activity seen in 2024.

When the malware issues the HTTP request, it uses a hardcoded User-Agent string:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/555.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36

The fetched file (8d2bb96e69df059f279d97989690ce3e556a8318) is a benign JPEG file, originating from publicly available photo stock, with no extra payload or any hidden cave where code could be embedded. We confirmed that an identical file can be found online, located on a web site that is nearly identical to the one used by attackers. It would seem the attackers not only reused the JPG file contents from a legitimate website but also copied its original URL, changing only the top level domain:

https://www.everythingandthedog.com/petsblog/2020/2/25/tips-for-taking-difficult-dogs-on-a-walk.

Once the file is downloaded, it is renamed and then saved to %APPDATA%\Roaming\Microsoft\SystemCertificates\CertificateCenter.dll.

Later, it is registered to load during autostart by leveraging the Registry Run key:

HKCU\System\Software\Microsoft\Windows\CurrentVersion\Run\Microsoft Certificate Center

with its value pointing to expanded environment variable string:

rundll32.exe C:\Users\\AppData\Roaming\Microsoft\SystemCertificates\CertificateCenter.dll,#1

This Registry entry makes rundll32.exe load the DLL and execute its exported function with ordinal 1 whenever a user logs on.

During our analysis we only observed the benign JPG file being downloaded. However, based on the code analysis, we believe that the real targets receive an actual DLL. We assume that such a targeted payload delivery process is carefully controlled by the attackers and that they deliver the payload only after confirming the requesting client’s profile (browser user agent, IP address of the client, and matching time of the operation window). Research in a previous campaign found that a Cobalt Strike payload was delivered to targets only if the host IP was located in Ukraine.

Given the timing and targeting of the attack, we hypothesized that it may not have been an isolated incident. Further research led us to discover other samples closely resembling Weaponized XLS 1, suggesting that multiple attacks using the same techniques had been planned or executed. The samples used in these suspected attacks are described below.

Weaponized XLS 2 | Ukraine Gov “Anti-Corruption Initiative”

A file bearing the Ukrainian name Zrazok.xls (“Sample.xls”) is an XLS file (301ffdf0c7b67e01fd2119c321e7ae09b7835afc) with an obfuscated VBA macro embedded. However, the script code and obfuscation technique are different from the case we discussed earlier.

For this script, the attackers used a popular obfuscator tool called Macropack, an open-source but seemingly abandoned project originally developed for red-teaming and penetration testing exercises.

As in the previous case, once the macro code is executed, the .NET ConfuserEx-obfuscated Downloader DLL (written to %AppData%\Roaming\Microsoft\bruhdll32.dll) is loaded with rundll32.exe and respective commandline arguments to run an exported function. After this, the new module drops a decoy XLS file and opens it with Excel.

This module attempts to download the next stage from the following URL (unavailable at the time of writing):

https://sciencealert[.]shop/images/2024/11/black-hole-coronaxx.jpg

When the malware issues the HTTP request it uses a hardcoded User-Agent string that differs slightly from the previous case:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36

Notably, this file (52e894acf0e14d27f8997d2174c1f40d6d87bba9) was previously uploaded to VirusTotal on December 19, 2024.

As with the previous case, the image file and its URL path appear to be copied from a public blog, published on Nov 16, 2024:

https://www.sciencealert.com/scientists-reveal-the-shape-of-a-black-holes-corona-for-the-very-first-time

Again, the file name and the path on the malicious server were nearly identical to the legitimate one, with the actor changing only the top level domain from .com to .shop.

https://www.sciencealert.com/images/2024/11/black-hole-coronaxx.jpg

In this case, the downloaded file is expected to be an archive in a GZIP format. Once downloaded, the malware decompresses it and saves it to the following location:

%APPDATA%\Roaming\Microsoft\SystemCertificates\CertificateCenter.dll

It also creates an additional text config file at:

%APPDATA%\Roaming\Microsoft\SystemCertificates\config

The config file contains the following data:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
 <PropertyGroup>
  <AssemblyName>Certificate</AssemblyName>
  <OutputPath>Bin\</OutputPath>
 </PropertyGroup>
 <ItemGroup>
  <Compile Include="CertificateCenter.dll" />
 </ItemGroup>
 <Target Name="Build">
  <MakeDir Directories="$(OutputPath)" Condition="!Exists('$(OutputPath)')" />
  <Csc Sources="@(Compile)" OutputAssembly="$(OutputPath)$(AssemblyName).exe" />
 </Target>
</Project>

The config file is used by the Downloader to execute MSBuild.exe, instructing it to build a new application:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe %AppData%\Roaming\Microsoft\SystemCertificates\config

This suggests that the CertificateCenter.dll file is not a binary as the file extension would suggest but rather contains program source code. The command, if successful, produces an executable file in the following location:

%AppData%\Roaming\Microsoft\SystemCertificates\Bin\Certificate.exe

and likely contains the next stage of the infection chain.

Weaponized XLS 3 | “Supplies for Ukraine Armed Forces”

A file bearing the Ukrainian name Донесення 5 реч - зразок.xls (“Report 5 items – sample.xls”) is an XLS file (9d110879d101bcaec7accc3001295a53dc33371f) hosting another VBA payload obfuscated with Macropack.

As in the previous cases, once the macro code is executed, the .NET ConfuserEx-obfuscated Downloader DLL (written to %AppData%\Roaming\Microsoft\bruhdll32.dll) is loaded with rundll32.exe and respective commandline arguments to run an exported function. After this, the new module drops a decoy XLS file on disk and opens it with Excel.

Again, the malware uses the same payload retrieval technique and downloads a JPG file from yet another .shop domain:

https://cookingwithbooks[.]shop/images/qwerty.jpg

The URL is unavailable at the time of writing, but data from VirusTotal indicates that the downloaded file is identical to the black hole image described above in the Weaponized XLS 2 section. The malware logic is also identical with Weaponized XLS 2.

Weaponized XLS 4 & 5 | Variations on a Theme

In addition to the previous findings, we discovered further related XLS files that were similarly weaponized. The files Донесення 5 реч фонд зборів- зразок.xls (“Report 5 items collection fund- sample.xls”; 2c06c01f9261fe80b627695a0ed746aa8f1f3744) and Додаток 8 реч новий.xls (“Addition 8 items new – sample.xls”; 853da593d2a489c2bd72a284a362d7c68c3a4d4c) were first uploaded from Ukraine in Feb 2025.

Both files contain a Macropack-obfuscated VBA macro; however, they differ in structure. Functionally, both drop a DLL to the previously noted path %AppData%\Roaming\Microsoft\bruhdll32.dll.

Again, the DLL is loaded with rundll32.exe and respective command line arguments to execute an exported function. Next, the victim sees a decoy workbook open in Excel.

The decoys are similar and the obfuscation technique, code structure, and the embedded URL are common to both:

https://pigglywigglystores[.]shop/wp-content/themes/fp-wp-j-piggly-wiggly-nc/resources/images/logo/logo.png

The User-Agent string in the HTTP request, however, is different, with the operating system and architectures specified as “Windows NT 10.0; Win64; x64”.

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36 Edg/97.0.1072.71

These variants of the malware also contain another embedded .NET DLL, internally referred to as LibCMD from the original filename LibCMD.dll (4ae6b8adc980ba8a212b838f3ca6a9718d9a3757). This is a small file, whose purpose is simply to start cmd.exe and connect to stdin/stdout.

The file contains a tampered PE link timestamp. It is never saved to disk; instead, it is loaded dynamically in memory as a .NET assembly and executed.

Attribution

Analysis of techniques used by threat actors can often be helpful in establishing the origin of the attack and the malware it uses. In this case, the obfuscation techniques are quite specific across all the samples we analyzed, allowing us to establish a medium confidence link between them and a malware cluster known as PicassoLoader, a downloader toolkit.

PicassoLoader has been used in cyber attacks targeting government, military, and civilian entities in Ukraine and Poland and is exclusively associated with the Ghostwriter threat actor (aka UNC1151, UAC-0057, Blue Dev 4, Moonscape, TA445).

Throughout 2024, Ghostwriter has repeatedly used a combination of Excel workbooks containing Macropack-obfuscated VBA macros and dropped embedded .NET downloaders obfuscated with ConfuserEx. In our case, the Downloader malware appears to be a simplified implementation of the PicassoLoader.

Conclusion

The Ghostwriter threat actor has been consistently active in the past years and continues its attempts to compromise targets aligned with the interests of Belarus and its closest ally, Russia. It has mounted multiple attacks reported by CERT UA and other security researchers throughout 2024.

While Belarus doesn’t actively participate in military campaigns in the war in Ukraine, cyber threat actors associated with it appear to have no reservation about conducting cyberespionage operations against Ukrainian targets.

The campaign described in this publication also serves as confirmation that Ghostwriter is closely tied with the interests of the Belarusian government waging an aggressive pursuit of its opposition and organizations associated with it.

We would like to express our thanks to partners in the region, including RESIDENT.NGO and others who remain unnamed, for their invaluable collaboration.

Organizations that believe they may have been targeted by threat actors involved in this campaign are invited to reach out to the SentinelLABS team via ThreatTips@sentinelone.com.

Indicators of Compromise

KEY TAKEAWAYS

• Volexity has observed multiple Russian threat actors conducting social-engineering and spear-phishing campaigns targeting organizations with the ultimate goal of compromising Microsoft 365 accounts via Device Code Authentication phishing.
• Device Code Authentication phishing follows an atypical workflow to that expected by users, meaning users may not recognize it as phishing.
• Recent campaigns observed have been politically themed, particularly around the new administration in the United States and the changes this might mean for nations around the world.

Starting in mid-January 2025, Volexity identified several social-engineering and spear-phishing campaigns by Russian threat actors aimed at compromising Microsoft 365 (M365) accounts. These attack campaigns were highly targeted and carried out in a variety of ways. The majority of these attacks originated via spear-phishing emails with different themes. In one case, the eventual breach began with highly tailored outreach via Signal.

Through its investigations, Volexity discovered that Russian threat actors were impersonating a variety of individuals in order to socially engineer targets, including impersonating individuals from the following:

• United States Department of State
• Ukrainian Ministry of Defence
• European Union Parliament
• Prominent research institutions

Communications carried a variety of different themes and messages, but they all ultimately resulted in the attacker inviting the targeted user to one of the following:

• Microsoft Teams Meeting / Video Conference
• Access to applications and data as an external M365 user
• Join a chatroom on a secure chat application

When these attacks were successful and the attackers gained access to accounts, the post-exploitation phase often had unique characteristics in each case:

• The way the attackers accessed material from compromised organizations (scripts versus native applications)
• The infrastructure used to access stolen accounts

Despite the differences, Volexity found the attacks had one thing in common: they were all Device Code Authentication attacks. While this attack method is not new, it is one that is definitely lesser known and not commonly leveraged by nation-state actors. Details on the social-engineering and spear-phishing campaigns, along with how Device Code Authentication attacks work, will be covered further in this blog post. What Volexity has observed is that this method has been more effective at successfully compromising accounts than most other targeted spear-phishing campaigns.

Volexity assesses with high confidence that the series of attacks described in this blog post are from Russia-based threat actors. At this time, Volexity is tracking this activity under three different threat actors and assesses with medium confidence that at least one of them is CozyLarch (overlapping with DarkHalo, APT29, Midnight Blizzard, CozyDuke). Volexity is tracking the remaining activity under UTA0304 and UTA0307. It is possible that all the activity described in this blog post is a single threat actor, but despite the similar targeting, timing, and attack method, other observed components of the operations are different enough to be tracked separately, for now.

From Secure Chat to Insecure Authentication

The discovery of this threat activity started toward the end of January 2025, when Volexity uncovered a highly targeted attack that had successfully compromised the M365 account of one of its customers. This breach was discovered after Volexity identified suspicious sign-in activity to the account, which was followed by a rapid download of files from the user's OneDrive. All authentication and download events came from virtual private server (VPS) and Tor IP addresses, which is not the most subtle way to access an account. Volexity noted this activity was likely scripted, as the User-Agent string for later access and file downloads was the Python User-Agent string python-requests/2.25.1.

Volexity then performed a detailed investigation into this incident, in an effort to identify how the account was compromised. A review of login activity showed the legitimate user had logged in and approved a multi-factor authentication (MFA) request. However, subsequent access was not from the legitimate user's IP address. This caused Volexity to initially suspect a phishing attack involving an adversary-in-the-middle (AiTM) framework. As a result, Volexity reviewed emails to the user leading up the time of the authentication event. This review identified a suspicious email just moments before the login activity from an email address purporting to be from someone with the name of a high-ranking official from the Ukrainian Ministry of Defence. The email was structured to look like a meeting invite for a chatroom on the messaging application, Element. Element is another encrypted messaging application that offers the ability for users to self-host a server with functionality that includes group video chats. The “invitation” email sent is shown below .

In fact, all hyperlinks in the email were linked to https://login.microsoftonline.com/common/oauth2/deviceauth, the page used for the Microsoft Device Code authentication workflow. Clicking the link leads to the dialogue shown below.

Microsoft describes the purpose of this workflow as allowing '"users to sign in to input-constrained devices such as a smart TV, IoT device, or a printer.” However, in this case, it means if an attacker can convince a user to enter a specific code into this dialogue (and log in), they are granted long-term access to the user’s account.

From Signal to Element

After working with its customer more closely, Volexity learned that the victim had been contacted on Signal by an individual purporting to be from the Ukrainian Ministry of Defence. This individual then requested the victim move off Signal to another secure chat application called Element. The attacker then had the victim join an Element server they controlled under the domain sen-comms[.]com. This allowed the attacker to further communicate with the victim in real time and inform them they needed to click a link from an email to join a secure chat room. This is where the email Volexity had discovered came into play. The message was a ploy to fool the user into thinking they were being invited into a secure chat, when in reality they were giving the attacker access to their account. The generated Device Codes are only valid for 15 minutes once they are created. As a result, the real-time communication with the victim, and having them expect the "invitation", served to ensure the phish would succeed through timely coordination.

The diagram below shows a high-level depiction of how the attack worked.

UTA0304 Infrastructure

Volexity tracks the threat actor behind this campaign as UTA0304. Through research conducted on the custom domain used by UTA0304 to operate its own Element server, Volexity was able to pivot and discover additional infrastructure it believes is likely operated by the group. The table below represents the list of infrastructure that Volexity has tied to this threat actor.

Spoofing the United States Department of State

In early February 2025, Volexity observed multiple spear-phishing campaigns targeting users with fake Microsoft invitations purporting to be from the United States (US) Department of State. These emails were themed as invitations to join the US Department of State’s Microsoft tenant as an external user, or as invitations to a Microsoft Teams chat named “Measuring Influence Operations".

Similar to the campaign conducted by UTA0304, these fake US Department of State emails were targeting users with a Device Code OAuth phishing workflow. Each email was aimed at convincing the user to accept the invitation and enter a unique code provided in the phishing email. The link in the invitations would direct users to the Microsoft Device Code authentication page. If the user entered the code provided in the phishing email, the authentication page would subsequently authorize the threat actor to access to the user’s account. However, it is worth noting that this campaign was sent out of the blue, with no precursor or build up to the emails, so users would not be expecting these messages. Even if they were to fall for the campaign, they would have to have done it within 15 minutes of receiving the email. This dramatically decreased the likelihood that this attack would be successful.

After reviewing various parts of the attack, Volexity assesses with medium confidence that the Russian threat actor CozyLarch (aka APT29 or Midnight Blizzard) was behind these US Department of State themed spear-phishing campaigns. Additional details on each campaign are described in the sections that follow.

Campaign 1: M365 Tenant External User Invitation

CozyLarch sent invitations to several users, inviting them to access applications within the M365 tenant for the US Department of State. The invitation email was designed to look like a real invitation that would be sent from Microsoft, as shown below.

In this instance, the “Accept invitation” hyperlink goes to https://www.microsoft.com/devicelogin, which is a simple redirect that sends the user to https://login.microsoftonline.com/common/oauth2/deviceauth.

The redirect link takes the user to the Microsoft Device Code OAuth workflow, and it is the same URL that UTA0304 directly embedded in their phishing campaign. However, unlike UTA0304, CozyLarch opted to use the redirect URL rather than the final login URL, perhaps because it may look even more recognizable to a discerning user, given that it is hosted on the main Microsoft domain. If the user entered the code provided from the email and continued through the authentication process, the attacker was granted access to the user’s M365 account.

Campaign 2: M365 Teams Chat Invitation

CozyLarch launched a second campaign, in which they targeted users with a fake invitation to join a Microsoft Teams chat named “Measuring Influence Operations”. The email made it appear as though there were already 37 other members in the chat.  A screenshot of one of the observed spear-phishing messages is shown below.

The “Sign in to Microsoft Teams” button in the email body is a hyperlink that leads to the same https://www.microsoft.com/devicelogin URL observed in the other campaign. The attack flow and end goal are the same, with only a small difference in the theme of the emails.

Email Source Analysis

The emails are designed to appear as though they come from Microsoft. The messages used mixed encoding in the “friendly” name that make the address difficult to discern. An example of the full “from” header used in one phishing email is given below:

\"Mic\udb40\udc30\udb40\udc30\udb40\udc30\u200br\udb40\udc30\udb40\udc30o\udb40\udc30\udb40\udc30soft Invitations on behal f of US Dep\udb40\udc30\udb40\udc30\udb40\udc30artme\udb40\udc30\udb40\udc30\udb40\udc30nt of St\udb40\udc30\udb40\udc30\udb40\udc30 ate \uff1cinvites\uff20mic\udb40\udc30\udb40\udc30\udb40\udc30\u200br\udb40\udc30\udb40\udc30o\udb40\udc30\udb40\udc30soft.co m\uff1e\u180e\u3000\u180e\u3000\u180e \u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000 \u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000 \u180e \u180e\u3000\u180e \u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e \u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e  \u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000 \u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000 \u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000 \u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000 \u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000 \u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000 \u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000\u180e\u3000 \u180e\u3000\u180e\u3000\u180e \u061c Cc:\" <sheilmagnett@gmail.com>

The attacker attempted to make it appear as if the emails were from invites@microsoft[.]com, and also set the Reply-To header as invites@microsoft[.]com. However, the true address could be seen at the end of the From: field; all messages were sent via Google Gmail accounts. Volexity observed the following Gmail accounts as the actual senders of the messages observed:

• brensonkarl@gmail[.]com
• kaylassammers@gmail[.]com
• kendisggibson@gmail[.]com
• leslytthomson@gmail[.]com
• mikedanvil@gmail[.]com
• sheilmagnett@gmail[.]com
• susannmarton@gmail[.]com

These addresses are believed to be controlled by CozyLarch and can be used to reliably detect phishing emails that may have been sent.

Using Wireless Proxy Networks for Email Distribution

Volexity also noted that the sending IP address associated with each spear-phishing email was recorded in the headers. Looking at the Received header in the messages, it became apparent that the attacker was using Proxy IP addresses based in the US to send messages. Volexity observed nearly a dozen IP addresses belonging to mobile networks in the US (AT&T and Verizon Wireless).

European Parliament and Donald Trump

Starting in late January through to the publication of this blog (February 13, 2025), Volexity has observed another campaign by a Russian threat actor it tracks as UTA0307 targeting numerous organizations. UTA0307 created a fake email under the identity of a member of the European Parliament who is on the Committee on Foreign Affairs. The threat actor reached out to numerous individuals with personalized emails requesting a Microsoft Teams meeting to discuss Donald Trump and his impact on relations between the US and the European Union. Volexity also observed a smaller set of campaigns centered on discussing China's foreign policy and China-European Union relations.

The email subject lines used in these various campaigns are listed below:

• Trump and EU
• Discussion on Eastern Europe and the Caucasus
• Discussion about Donald Trump's new term
• Discussion about Trump & US relations with Europe
• Collaboration on China and East Asia Research

The image below shows an example spear phish that was sent by UTA0307.

None of the initial emails contained any malicious content or links at the onset. The threat actor was leveraging a tactic that has become commonplace for numerous nation-state actors, where they wait until a conversation has started prior to sending anything malicious. This serves the purpose of knowing they have an engaged target, and that the target's guard is potentially down. In the specific cases of Device Code Authentication phishing, it is especially important to have a responsive target, as the threat actor has only 15 minutes to convince the target to enter the code that has been generated.

A Different Device Code OAuth Phishing Technique

Volexity actually discovered the operations of UTA0307 following a successful compromise. Similar to the initial discovery of UTA0304, Volexity worked backwards from detecting a breach to identifying the above spear-phishing emails. In this case, the victim had engaged from the initial email and had several messages back and forth with UTA0307 regarding a meeting being set up. They agreed to join a Microsoft Teams meeting, and a fake invitation email was sent. However, this time the link in the email did not go to Microsoft. The target received an email with the subject "Join Teams meeting", and the body of the email, shown below, was designed to look like a real invitation.

The “Join the meeting now” hyperlink, however, linked to a website controlled by UTA0307 (connect-71q.pages[.]dev). This page in turn was set up to automatically generate a new Microsoft Device Code each time it was visited. The website was designed to appear as an official Microsoft interstitial page before the user can join a Microsoft Teams meeting. The message that appears on the landing page (shown below) claims that the victim needs to pass a security check by copying a code and entering it on a subsequent page

When the user clicks the “Next” button, a new tab is opened with the real Microsoft Device Code Authentication interface that requests an authentication code. If the victim enters the code supplied by the phishing page, they grant UTA0307 access to their M365 account. Interestingly, in the background of the initial phishing page, Volexity noted that the website would continuously poll the domain rosejob[.]com. It appears this domain was set up to monitor successful Device Code Authentication and, if detected, would redirect the user to a real Microsoft Teams meeting URL in an effort to make the activity appear legitimate.

The threat actor never joined this Microsoft Teams meeting. However, UTA0307 did add authorization for an authentication application under their control to enable multi-factor authentication when logging into the compromised account. Volexity assesses with medium confidence that this was a requirement of logging into the account, even with the stolen authentication token.

One benefit of this attack workflow versus other previously observed DeviceID phishing workflows is that, when a DeviceID code is generated, it is only valid for 15 minutes. Having an interstitial page that automatically generates new codes means UTA0307 does not have to worry about their phishing content expiring.

UTA0307 Post-compromise Activities, Targeting and Attribution

Volexity observed UTA0307 exfiltrating documents from a compromised M365 account that would be of interest to a Russian threat actor. This was determined based on identification of FileDownloaded operations observed in M365 audit log data. Given this information about the threat actor’s objectives, their targeting, and their use of a highly similar technique to that used in recent days and weeks by CozyLarch and UTA0304, Volexity assesses with medium confidence that UTA0307 is also a Russian threat actor.

However, the exact implementation of the DeviceID OAuth phishing technique used in this activity differs slightly from those previously documented by Volexity, which provides some evidence that this activity may have been conducted by a separate threat actor. For example, while the previously observed phishing campaigns saw the attacker use the client ID for Microsoft Office when handling Device Code Authentication, this activity instead used the client ID for Microsoft Teams, as shown below (note that Microsoft uses appId and client_id interchangeably in their logs when referring to the ID for an application):

"appDisplayName": "Microsoft Teams",

"appId": "1fec8e78-bce4-4aaf-ab1b-5451cc387264",

Another difference between this and the UTA0304 campaign is that in this case, all subsequent access to the compromised account occurred via Mullad VPN exit nodes (versus the other observed VPS and Tor IP addresses). Based on these two factors, Volexity has chosen to track this activity under the UTA0307 alias, rather than CozyLarch or UTA0304.

Detecting Device Code Authentication

Volexity identified a way to reliably detect this attack through monitoring and analysis of Microsoft Entra ID sign-in logs. When a user enters a device code and subsequently authenticates, it results in a login to the application associated with the generated code. This can be a common application like Microsoft Office that is frequently accessed by users and would not be a reliable indicator. However, the good news is that Device Code Authentications result in the authenticationProtocol field being set with the value deviceCode.

The line below is what will appear in the JSON data in the Entra ID sign-in logs when a Device Code Authentication occurs:

“authenticationProtocol": "deviceCode",

Volexity further noted that as authenticated sessions refresh and are kept alive, subsequent sign-ins that initially occurred via a deviceCode often do not have anything set for authenticationProtocol, but they contain the following entry:

  “originalTransferMethod": "deviceCodeFlow",

These values can be searched and filtered on in the Entra Admin center by adding filters for "Authentications Protocol" and "Original Transfer Method". The latter can be filtered in both interactive and non-interactive sign-ins. The frequency and legitimacy of these values occurring in the sign-in logs for a particular organization may vary, as this is a legitimate Microsoft feature. An organization can evaluate their risk and usage of these workflows, and potentially use this information as a proactive detection mechanism.

If an organization has the ability to monitor URLs that are being accessed by users or sent in email, there are additional detection opportunities to discover Device Code Authentication attacks. The following official URLs can be monitored for as related to Microsoft Device Code Authentication:

• https://login.microsoftonline.com/common/oauth2/deviceauth
• https://www.microsoft.com/devicelogin
• https://aka.ms/devicelogin

Organizations can monitor for access to these URLs or for their presence in various communication methods, such as email. Attackers can find other means to redirect users to these URLs, but one of the main advantages of using the list above in phishing attacks is that the URL displayed is hosted on a legitimate Microsoft domain.

Preventing Device Code Authentication

Volexity believes the most effective way to prevent this potential attack vector is through conditional access policies on an organization's M365 tenant. It is possible for organizations to create a conditional access policy that disallows device code authentication altogether. It is fairly trivial to set up, and Microsoft provides online guidance on exactly how to do this. Based on Volexity's own testing, blocking the "Device code flow" from "Authentications flows" prevents this attack from working.  The image below shows what a conditional access policy would look like once it's set up and in place to block this authentication flow.

Prior to implementing such a policy, organizations should evaluate the use of Device Code Authentication in their environment. This feature is used legitimately, and blocking it could have a negative impact. Volexity's review of its own customers identified several instances of legitimate access to resources via these means. However, at the majority of Volexity's customers, there was either no recent Device Code Authentication activity or there was only activity tied to the attacks described in this blog post.

Conclusion

Volexity continues to track multiple spear-phishing campaigns targeting Device Code Authentication. This blog post serves to cover a few of the larger and unique campaigns observed. Volexity has observed other similar spear-phishing campaigns in recent weeks targeting Device Code Authentication that it believes are the work of Russian threat actors. Further, it should be noted that it is possible this is the work of a single threat actor running multiple, different campaigns. However, at this time, Volexity believes this activity is sufficiently different enough to warrant tracking this activity under two different unknown threat actors and one it believes is likely CozyLarch.

While Device Code Authentication attacks are not new, they appear to have been rarely leveraged by nation-state threat actors . Volexity's visibility into targeted attacks indicates this particular method has been far more effective than the combined effort of years of other social-engineering and spear-phishing attacks conducted by the same (or similar) threat actors. It appears that these Russian threat actors have made a concerted effort to launch several campaigns against organizations with a goal of simultaneously abusing this method before the targets catch on and implement countermeasures.

The detection mechanisms and countermeasures to these attacks have been available for years. However, Volexity believes they are seldom implemented and that most organizations are not even aware of this authentication flow, let alone the means to detect its misuse. These attacks serve as a reminder that threat actors will constantly look for ways to abuse legitimate features, and organizations must continually evaluate and implement methods to detect and prevent such attacks.

These attacks also serve as a good opportunity to engage with users and remind them to be on the lookout for anything out of the ordinary when it comes to accessing resources when they are asked for login credentials or authorization grants. This phishing workflow has proven useful for an attacker, as many traditional sources of evidence and detection, both for a user and network defenders, are not present. For example:

1. There is no “malicious” link or attachment. The only link is to the provider’s infrastructure (in this case, Microsoft). This means users cannot easily identify the link as being suspicious, and automated solutions detecting malicious emails will likely fail to do so for the same reason.
2. Users are generally less aware of attacks that leverage legitimate services, and may be even less aware when it comes to those that involve entering a device code rather than their username or password.
3. After successful authentication, the logs will show the authenticating application as a legitimate or benign application, reducing signal that can be keyed off of in sign-in logs by detection teams.

These are items that organizations should look to further train users on and implement technical countermeasures against where possible.

Indicators associated with these campaigns are available on the Volexity GitHub.

If you believe you have been targeted by a similar attack and want to share details with Volexity for informational purposes, additional investigation, or incident response, please contact us.

Volexity's Threat Intelligence research, such as the content from this blog, is published to customers via its Threat Intelligence Service. The activity described in this blog post was shared with Volexity Threat Intelligence customers in TIB-20250206, TIB-20250211, and TIB-20250213.

 

If you are interested in learning more about Volexity’s services, including Network Security Monitoring and Incident Response, or our leading memory forensics solutions, Volexity Surge Collect Pro for memory acquisition and Volexity Volcano for memory analysis, please do not hesitate to contact us.

The post Multiple Russian Threat Actors Targeting Microsoft Device Code Authentication appeared first on Volexity.