{
	"id": "0a0929d0-16d4-4ca6-94d4-39230dc96c69",
	"created_at": "2026-04-06T00:16:21.871629Z",
	"updated_at": "2026-04-10T13:12:08.138842Z",
	"deleted_at": null,
	"sha1_hash": "463b61592345847f676676c8b0da98688aba3234",
	"title": "Phishing for Codes: Russian Threat Actors Target Microsoft 365 OAuth Workflows",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1828700,
	"plain_text": "Phishing for Codes: Russian Threat Actors Target Microsoft 365 OAuth\r\nWorkflows\r\nBy mindgrub\r\nPublished: 2025-04-22 · Archived: 2026-04-05 16:16:24 UTC\r\nSince early March 2025, Volexity has observed multiple suspected Russian threat actors conducting highly targeted social\r\nengineering operations aimed at gaining access to the Microsoft 365 (M365) accounts of targeted individuals. This activity\r\ncomes on the heels of attacks Volexity reported on back in February 2025, where Russian threat actors were discovered\r\ntargeting users and organizations through Device Code Authentication phishing.\r\nSince that reporting, while there has been an observable drop in Russian threat actors leveraging that specific method,\r\nVolexity has observed them pivoting to different methods of attack that abuse other legitimate M365 OAuth authentication\r\nworkflows. These recently observed attacks rely heavily on one-on-one interaction with a target, as the threat actor must\r\nboth convince them to click a link and send back a Microsoft-generated code.\r\nVolexity is currently tracking what is believed to be at least two Russian threat actors, which it tracks as UTA0352 and\r\nUTA0355, that are behind these attacks. It is plausible that there are overlaps between these threat actors and those Volexity\r\npreviously reported as conducting Device Code Authentication phishing campaigns in January and February 2025. This blog\r\npost details the different techniques used by these threat actors and the commonalities between their campaigns, which can\r\nbe summarized as follows:\r\nThe attacker contacts the victim via a messaging application (Signal, WhatsApp) and invites them to join a video call\r\nto discuss the conflict in Ukraine.\r\nOnce the victim has responded, the attacker sends an OAuth phishing URL that they claim is required to join the\r\nvideo call.\r\nThe victim is asked to return the Microsoft-generated OAuth code back to the attacker.\r\nIf the victim shares the OAuth code, the attacker is then able to generate an access token that ultimately allows access\r\nthe victim’s M365 account.\r\nDiplomatic Channels to Nowhere\r\nIn March 2025, Volexity learned that some of its customers’ staff were receiving suspicious messages via Signal and\r\nWhatsApp. The targeted staff members worked at NGOs that support human rights and specifically have expertise and\r\nexperience working on issues related to Ukraine. The messages claimed to be from European political officials and were\r\nthemed around discussing matters involving Ukraine. In each observed instance, the call to action was to arrange a meeting\r\nbetween the target and a political official, or Ambassador, of the European country of which the sender claimed to represent.\r\nIf the target responded to messages, the conversation would quickly progress towards actually scheduling an agreed upon\r\ntime for the meeting. However, perhaps in an attempt to not arouse suspicion, in some cases the “Ambassador” would not be\r\nimmediately available, and the meeting would be scheduled for days later.\r\nAs the agreed meeting time approached, the purported European political official would make contact again and share\r\ninstructions on how to join the meeting. These instructions typically came in the form of a document uploaded into the\r\nmessaging platform. This “official” would then send a link for the target to click on in order to join the meeting. These\r\nshared URLs all pointed to the official login portal for M365 via login.microsoftonline.com.\r\nIt should come as no surprise that these were, in fact, phishing campaigns, and the supplied instructions involved sending a\r\ncode back to the attacker. However, unlike the previously observed attacks, these URLs were not associated with Device\r\nCode Authentication workflows. Instead, these URLs pointed to other Microsoft OAuth 2.0 authentication workflows\r\nassociated with various legitimate first-party Microsoft applications. Volexity attributes the initial series of attacks observed\r\nto a suspect Russian threat actor it tracks as UTA0352.\r\nIn these campaigns, clicking the link alone would not be enough for the account to be compromised. The code would need to\r\nbe supplied back to the attacker. The supplied links would redirect to official Microsoft URLs and, in the process, generate a\r\nMicrosoft Authorization Token that would then appear as part of the URI, and in some cases, within the body of the redirect\r\npage. This code could then be used to generate an Access Token, which would grant the holder with access to the account for\r\nwhich it was generated. In multiple observed instances, the attacker would request the code be emailed or sent back via\r\nWhatsApp or Signal.\r\nhttps://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/\r\nPage 1 of 9\n\nVolexity observed UTA0352 impersonating individuals representing the following countries and affiliations:\r\nMission of Ukraine to the European Union\r\nPermanent Delegation of the Republic of Bulgaria to NATO\r\nPermanent Representation of Romania to the European Union\r\nBased on other observations, Volexity believes UTA0352 also likely impersonated officials from Poland as well, but\r\nVolexity did not observe this directly. The images below show examples of initial outreach messages sent by UTA0352\r\nimpersonating various identities on Signal (left) and WhatsApp (right).\r\nPhishing via Visual Studio Code\r\nIn mid-March 2025, one of Volexity’s customers was contacted by UTA0352 claiming to be a government official from\r\nRomania. They attempted to set up a meeting with their Ambassador. Once the user engaged, the attacker sent a message\r\nexplaining the need to set up a meeting on their web-based “Extended Verification System (EVS)” hosted on their secure\r\nservers. This message was accompanied by a PDF file with instructions on what to expect and how to join, after which a\r\nmaliciously crafted URL was sent to the target.\r\nThe image below shows the two-page PDF document purporting to be from the Romanian Ministry of Foreign Affairs.\r\nhttps://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/\r\nPage 2 of 9\n\nThe URL shared by UTA0352 had the following format:\r\nhttps://login.microsoftonline[.]com/organizations/oauth2/v2.0/authorize?\r\nstate=https://mae.gov[.]ro/[REMOVED]\u0026client_id=aebc6443-996d-45c2-90f0-\r\n388ff96faa56\u0026scope=https://graph.microsoft.com/.default\u0026response_type=code\u0026redirect_uri=https://insiders.vscode.dev/redirect\u0026log\r\n\u003cEMAIL HERE\u003e\r\nThis URL format is used by M365 to log in to both Microsoft-native/first-party applications and third-party applications\r\nusing M365’s OAuth workflows. The key parameters of the URL are described in the Microsoft OAuth documentation; for\r\nconvenience, they are briefly described below:\r\nParameter Description\r\nstate A value to denote the user’s state in the application before the request occurred\r\nclient_id The application that made the request\r\nscope The access level requested\r\nresponse_type The method used to send the token back\r\nredirect_uri The handling URI to receive the generated token afterwards\r\nIf the user is already logged in with the account specified in the login_hint parameter, they will be seamlessly redirected.\r\nIf the user is not already authenticated, they will be prompted to log in to their M365 account. Once authenticated, the user\r\nis redirected to an in-browser version of Visual Studio Code, hosted at insiders.vscode.dev. The URL redirects the user to\r\nthe /redirect page, which is designed to receive login parameters from M365, including OAuth. When the user is\r\nredirected to this page, they are presented with the following dialog:\r\nhttps://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/\r\nPage 3 of 9\n\nThe code displayed via the Visual Studio Code dialog is an OAuth 2.0 authorization code that can be used for up to 60 days.\r\nThis code can be submitted to Microsoft’s OAuth workflow for an access token, which can then be used to access the M365\r\nGraph API. Since the original request asked for the user’s default access rights, anyone with access to this authorization code\r\nalso has access to all resources normally available to the user. It should be noted that this code also appeared as part of the\r\nURI in the address bar. The Visual Studio Code appears to have been set up to make it easier to extract and share this code,\r\nwhereas most other instances would simply lead to blank pages.\r\nThe message shown under the main header uses the state value from the prior request, which is commonly used to\r\nindicate where the request to authenticate came from. However, as described in Microsoft’s documentation, this value is\r\narbitrary. It is up to the handling application (in this case, Visual Studio Code) to decide if and how to use this value.\r\nUTA0352 abused this to make it look like an authentication attempt to a Romanian government service. This is a theme\r\nrepeated in other phishing attacks as an effort to make the links appear legitimate.\r\nThe diagram below shows the overall workflow followed by the attacker to target users leveraging the Visual Studio Code\r\nfirst-party application. The workflow varies slightly from other attacks observed later but is fairly similar overall.\r\nhttps://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/\r\nPage 4 of 9\n\nEarlier Variations of Visual Studio Code Phishing\r\nIn addition to the phishing attack described above, Volexity also identified an older variation of a phishing campaign\r\nbelieved to have been employed by UTA0352. In this earlier campaign, the following URL format was used:\r\nhxxps://login.microsoftonline[.]com/common/oauth2/authorize?\r\nredirect=https://zoom.us/j/\u003csnip\u003e\u0026client_id=aebc6443-996d-45c2-90f0-\r\n388ff96faa56\u0026resource=https://graph.microsoft.com\u0026response_type=code\u0026redirect_uri=https://vscode-redirect.azurewebsites.net\u0026login_hint=\u003cremoved\u003e\u0026ui_locales=en-US\u0026mkt=en-US\u0026client-request-id=\r\n\u003cremoved\u003e\r\nThe URL differs from the one previously described, in that it employs the format used by the AzureAD v1.0 specification,\r\nnot v2.0 used in the initially observed campaign. The key differences between the URL parameters used are noted below:\r\nParameter Initially Observed Campaign Earlier Campaign Variation\r\nredirect_uri Uses insiders.vscode.dev Uses vscode-redirect.azurewebsites.net .\r\nresource\r\nThis is the scope parameter in\r\nthe Oath 2.0 flow\r\nThis is the AzureAD v1.0 field used to define the resource for\r\nwhich access is required\r\nredirect\r\nUnused in the previously\r\ndocumented campaign\r\nThis parameter is included in the request to make it look like the\r\nuser may be logging into a Zoom call, but it is unused in\r\nAzureAD v1.0 authentication workflows\r\nThe workflow the older campaign variation initiates is similar to the initially observed campaign. If a user is logged in, they\r\nare redirected to vscode-redirect.azurewebsites.net, which in turn redirects to a local IP address (127.0.0.1). When this\r\nhappens, instead of yielding a user interface with the Authorization Code, the code is only available in the URL. The final\r\nURL is in the following format:\r\nhxxp://127.0.0.1:9217/callback?code=1.ARsAIGLD9ki0FE63WmhS-KbgFENkvK5tmX[snipped]D\u0026session_state=\r\n[uuid]\r\nThis yields a blank page when rendered in the user’s browser. The attacker must request that the user share the URL from\r\ntheir browser in order for the attacker to obtain the code.\r\nUTA0355: Phishing via Compromised Ukrainian Government Account\r\nThen, in early April 2025, Volexity identified another new Microsoft 365 OAuth phishing campaign. This time, the\r\ncampaign started with an email from a legitimate, compromised Ukrainian Government email account, which was then\r\nfollowed by messages sent via Signal and WhatsApp. The emails and follow-up messages invited targets to join a video\r\nconference related to Ukraine’s efforts “to investigate and prosecute atrocity crimes, as well as the country’s cooperation\r\nwith international partners in this field.”\r\nAs with previous OAuth phishing techniques that Volexity has reported, the ultimate intention of this campaign is to use the\r\nlegitimate Microsoft 365 authentication API to gain access to the victim’s email data. However, in this campaign, the\r\nattacker uses the stolen OAuth authorization code to register a new device to the victim’s Microsoft Entra ID (formerly\r\nAzure Active Directory) on a permanent basis. After registering the device in Entra ID, the attacker then needs to further\r\nsocially engineer the target into approving a two-factor authentication request in order to gain access to the victim’s email.\r\nWhile this campaign uses similar techniques to those employed by UTA0352, Volexity currently tracks these attacks\r\nseparately and attributes this activity to a threat actor it has labeled UTA0355.\r\nMulti-stage Social Engineering\r\nUnlike the attacks that Volexity observed from UTA0352, this new phishing campaign started with an email that was sent to\r\nmultiple targets. The email invited the targets to a video conference and included the event details. The email did not include\r\nany links or instructions, but it did solicit interest from the recipient on if they wished to attend. However, despite the initial\r\noutreach coming via email, Volexity found that UTA0355 quickly followed up with each recipient via Signal or WhatsApp,\r\nreferencing the email that was sent, likely to add legitimacy to their messaging.\r\nVolexity believes that UTA0355 only sent the email from the compromised Ukrainian Government account to individuals\r\nfor whom it had out-of-band contact information. This was likely to facilitate real-time conversations to assist with social\r\nengineering efforts, and to keep information outside of email where it could more easily be discovered or later examined.\r\nhttps://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/\r\nPage 5 of 9\n\nThe initial email that was sent to various targets is shown in the image below.\r\nNot long after this email was sent to various targets, the follow-up message from UTA0355 referencing the email was sent\r\nvia Signal or WhatsApp; an example of which is shown below.\r\nOAuth Phishing and the Device Registration Service\r\nLike other OAuth phishing techniques, the one used in this campaign involved direct interaction with the victim to have\r\nthem click a link and supply a code back to the attacker. This code is then sought by the attacker and used to obtain illicit\r\naccess to M365 resources.\r\nVictim Interaction\r\nIf the target responded to the message UTA0355 sent via Signal or WhatsApp, they would be sent an M365 login URL to\r\nclick; the URL format is shown below:\r\nhttps://login.microsoftonline.com/common/oauth2/authorize?\r\nurl=https://teams.microsoft.com/[redacted]\u0026client_id=29d9ed98-a469-4536-ade2-\r\nhttps://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/\r\nPage 6 of 9\n\nf981bc1d605e\u0026resource=01cb2876-7ebd-4aa4-9cc9-\r\nd28bd4d359a9\u0026response_type=code\u0026redirect_uri=https%3A%2F%2Flogin.microsoftonline.com%2FWebApp%2FCloudDomainJoin%2F8\u0026amr_values=n\r\n\u003cemail@address.here\u003e\r\nAfter the victim logged in via the shared Microsoft URL, they would be redirected to a new URL that contained an OAuth\r\nauthorization code within the URL. The attacker included additional instructions indicating the victim should share the URL\r\nthey see in their address bar after the redirect occurs. The URL generated by the victim’s browser, and subsequently returned\r\nto UTA0355, follows the format below:\r\nhttps://login.microsoftonline.com/WebApp/CloudDomainJoin/8?code=[redacted]\u0026session_state=[redacted]\r\nBy sharing this URL with the attacker, the victim would unknowingly hand over all the information required to authenticate\r\nas themselves. This is similar to other observed and suspected attack campaigns. And again, this does require the target to\r\nboth click a link and send back a code or URL. However, the victim is only ever asked to interact with legitimate Microsoft\r\n365 services, which users may inherently see as trustworthy. Additionally, it may not immediately appear obvious to a user\r\nthat sharing data from their address bar, or from text displayed on a legitimate Microsoft webpage, would facilitate granting\r\nan attacker access to their M365 account.\r\nUTA0355 OAuth Abuse\r\nThe URL the victim would share with the attacker includes a code parameter containing an OAuth authorization code, which\r\nwould then be used to grant access tokens. Unlike similar previous campaigns, the resource requested in the initial login is\r\nnot access to the Microsoft Graph API; instead, it is for the Device Registration Service. This service is used by Windows to\r\njoin new devices to Entra ID. The attacker would use this access to join a new device named DESKTOP-[redacted] to the\r\nvictim’s Entra ID. Volexity was able to use the ROADTools project to replicate these steps, and followed this guide to create\r\na new token with full permissions for Microsoft Graph API access. This technique uses a flaw in the Entra ID API design to\r\ngrant an access token with a greater level of access than that initially granted.\r\nAfter the initial interaction had taken place, and UTA0355 had registered their device with the victim’s Microsoft Entra ID\r\n(Azure AD), Volexity observed an additional interaction with the victim. In this interaction, UTA0355 requested that the\r\nvictim approve a two-factor authentication (2FA) request to “gain access to a SharePoint instance associated with the\r\nconference”. This was required to bypass additional security requirements, which were put in place by the victim’s\r\norganization, in order to gain access to their email.\r\nPost-compromise Activity\r\nVolexity assesses with high confidence that the attacker required the victim to approve a 2FA request to access email items.\r\nIn logs reviewed by Volexity, initial device registration was successful shortly after interacting with the attacker. Access to\r\nemail data occurring the following day, which was when UTA0355 had engineered a situation where their 2FA request\r\nwould be approved. Once access was granted, logs showed the attacker downloaded the target’s email using a session tied to\r\nthe newly registered device.\r\nThe login activity, email access, and device registration all took place using a client IP address belonging to a proxy network\r\nthat was geolocated to where the victim was located.\r\nDetecting Related Activity\r\nTo generally prevent or detect these attacks, Volexity recommends the following:\r\nConsider alerting on M365 login activity where the Visual Studio Code client_id value aebc6443-996d-45c2-\r\n90f0-388ff96faa5 is used in combination with a resourceDisplayName containing “Microsoft Graph”. Depending\r\non your environment and the usage of Visual Studio Code, this may or may not be feasible, as legitimate users will\r\nalso login using this client_id .\r\nConsider alerting on the following URL format (either embedded in email or proxy logs). Note that the parameters in\r\nthe URL can appear in any order, and that the redirect_uri values must be set to insiders.vscode.dev/redirect\r\nor vscode-redirect.azurewebsites.net :\r\nhttps://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?state=\r\n[any_url]\u0026client_id=aebc6443-996d-45c2-90f0-\r\n388ff96faa56\u0026scope=https://graph.microsoft.com/.default\u0026response_type=code\u0026login_hint=\r\n[email]\u0026redirect_uri=https://insiders.vscode.dev/redirect\r\nhttps://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/\r\nPage 7 of 9\n\nhttps://login.microsoftonline[.]com/common/oauth2/authorize?redirect=\r\n[any_url]\u0026client_id=aebc6443-996d-45c2-90f0-\r\n388ff96faa56\u0026resource=https://graph.microsoft.com\u0026response_type=code\u0026redirect_uri=https://vscode-redirect.azurewebsites.net\u0026login_hint=[email]\u0026ui_locales=en-US\u0026mkt=en-US\u0026client-request-id=\r\n[removed]\r\nEvaluate the business impact associated with blocking access to the insiders.vscode[.]dev and vscode-redirect.azurewebsites.net hostnames and consider implementing such blocks.\r\nEducate users about the risks associated with new and unknown contacts established through secure messaging\r\nplatforms. It is crucial that users understand the importance of verifying the identities of contacts that reach out via\r\nSignal, WhatsApp, or other secure messaging platforms. Verification should be done out-of-band instead of trusting\r\ninformation provided via unsolicited or unexpected outreach.\r\nConsider looking for newly registered devices, and correlate with registering IP addresses to look for low-reputation\r\nor proxy IP addresses appearing in the ClientIPAddress .\r\nBe aware that ongoing access to the user’s email via the Microsoft Graph API will not contain an attacker IP\r\naddress in the ClientIPAddress field; instead, it contains a Microsoft IP address. This behavior does not\r\nappear to be documented and is counterintuitive to security analysis.\r\nWhile attacker activity cannot easily be tracked via the ClientIPAddress field, Volexity was able to track\r\nattacker activity based on the unique deviceId value associated with the device that was registered by the\r\nattacker.\r\nThe ClientAppID field for ongoing access may differ from the user’s typical email client, as it will use an\r\nAppID corresponding to one created by the attacker.\r\nConsider implementing conditional access policies that restrict access to organizational resources to only approved or\r\nmanaged devices. This can be effective at preventing device registration and unauthorized access to other resources\r\nsuch as email.\r\nAt the time of publication, Volexity is not aware of a way to block specific first-party Microsoft apps via\r\nconditional access policies. Conditional access can be used to block access to all services for non-compliant\r\ndevices; however, this may prove challenging for organizations to implement in a short timeframe.\r\nIt should also be noted that Microsoft Teams was one of the resources Volexity also observed UTA0352\r\ntargeting. It is not likely reasonable or feasible for most organizations to block this, if it were even possible.\r\nConclusion\r\nMotivated threat actors will continuously look for new ways to circumvent security controls and gain access to resources\r\nusing new methods that are not well known to users or cyber defense teams. This latest series of attacks marks the second\r\ntime since January 2025 that Russian threat actors have blitzed little-known techniques to obtain access to M365 resources.\r\nVolexity surmises that these attacks targeting NGOs, Think Tanks, and human rights defenders may be ramping up in order\r\nto capitalize on the current situation these individuals and organizations are facing in the form of budget cuts and reduced\r\nstaffing.\r\nSimilar to the Device Code Authentication phishing campaigns that Volexity reported in February 2025, these recent\r\ncampaigns benefit from all user interactions taking place on Microsoft’s official infrastructure; there is no attacker-hosted\r\ninfrastructure used in these attacks. Similarly, these attacks do not involve malicious or attacker-controlled OAuth\r\napplications for which the user must explicitly grant access (and thus could easily be blocked by organizations). The use of\r\nMicrosoft first-party applications that already have consent granted has proven to make prevention and detection of this\r\ntechnique rather difficult.\r\nOrganizations should train users to be highly vigilant when it comes to unsolicited contact, especially if it arrives via secure\r\nmessaging apps and request that users click links or open attachments. Further, for this specific type of attack to be\r\nsuccessful, the attacker must request that the user send back a URL or code from the link they clicked on. This tactic is not\r\nsomething users are typically trained to be aware of and should be added to an organization’s users’ security awareness\r\ntraining.\r\nAt this time, Volexity notes that NGOs, organizations related to human rights and providing aid and humanitarian assistance,\r\nand those with ties to Ukraine are likely the most at risk and potential targets of these campaigns. And while this threat\r\nactivity is ongoing in limited targeted attacks, Volexity expects that this method of attack will continue and may become\r\nmore widespread. Therefore, organizations should broadly warn users about this type of attack.\r\nFinally, all messages attributed to UTA0352 and UTA0355 were themed around Ukraine, and targeted numerous individuals\r\nand organizations that have historically been targeted by Russian threat actors. Based on this, and the use of similar tactics\r\nhttps://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/\r\nPage 8 of 9\n\nobserved in February 2025, Volexity assesses with medium confidence that both UTA0352 and UTA0355 are Russian threat\r\nactors. It is unclear if they are working in coordination or have overlaps with Volexity’s previous reporting.\r\nINVESTIGATIVE ASSISTANCE\r\nIf any organization or individual believes they may have been targeted by UTA0352, UTA0355, or in a similar\r\nattack, please feel free to reach out to Volexity via our contact form. We would be glad to assess any potential\r\ntargeting and assist in determining if such an attack may have succeeded.\r\nAcknowledgements\r\nVolexity would like to thank its customers for their vigilance, cooperation, hard work, and dedication to defending human\r\nrights. Volexity would also like to thank the MIL.CERT-UA of the Ministry of Defence of Ukraine for their ongoing\r\nassistance and cooperation.\r\nSource: https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/\r\nhttps://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MISPGALAXY",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/"
	],
	"report_names": [
		"phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows"
	],
	"threat_actors": [
		{
			"id": "ff18e901-c95b-4978-bd40-e298fd7a3466",
			"created_at": "2025-05-29T02:00:03.234474Z",
			"updated_at": "2026-04-10T02:00:03.882915Z",
			"deleted_at": null,
			"main_name": "UTA0355",
			"aliases": [],
			"source_name": "MISPGALAXY:UTA0355",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "fab0f3c2-cf6a-40ca-915e-566e4e69c951",
			"created_at": "2025-05-29T02:00:03.235919Z",
			"updated_at": "2026-04-10T02:00:03.883672Z",
			"deleted_at": null,
			"main_name": "UTA0352",
			"aliases": [],
			"source_name": "MISPGALAXY:UTA0352",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434581,
	"ts_updated_at": 1775826728,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/463b61592345847f676676c8b0da98688aba3234.pdf",
		"text": "https://archive.orkl.eu/463b61592345847f676676c8b0da98688aba3234.txt",
		"img": "https://archive.orkl.eu/463b61592345847f676676c8b0da98688aba3234.jpg"
	}
}