{ "id": "4b339e75-e5b0-4f0e-8957-4efb7a7a8de4", "created_at": "2026-04-06T00:13:34.663798Z", "updated_at": "2026-04-10T13:13:02.496275Z", "deleted_at": null, "sha1_hash": "4a216180518b7ec5c50c65563b5ddf06097093e8", "title": "StellarParticle Campaign: Novel Tactics and Techniques | CrowdStrike", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 2573224, "plain_text": "StellarParticle Campaign: Novel Tactics and Techniques |\r\nCrowdStrike\r\nBy CrowdStrike Services - CrowdStrike Intelligence\r\nArchived: 2026-04-05 14:09:41 UTC\r\nStellarParticle is a campaign tracked by CrowdStrike as related to the SUNSPOT implant from the\r\nSolarWinds intrusion in December 2020 and associated with COZY BEAR (aka APT29, \"The Dukes\").\r\nThe StellarParticle campaign has continued against multiple organizations, with COZY BEAR using novel\r\ntools and techniques to complete their objectives, as identified by CrowdStrike incident responders and the\r\nCrowdStrike Intelligence team.\r\nBrowser cookie theft and Microsoft Service Principal manipulation are two of the novel techniques and\r\ntools leveraged in the StellarParticle campaign and are discussed in this blog.\r\nTwo sophisticated malware families were placed on victim systems in mid-2019: a Linux variant of\r\nGoldMax and a new implant dubbed TrailBlazer.\r\nSupply chain compromises are an increasing threat that impacts a range of sectors, with threat actors leveraging\r\naccess to support several motivations including financial gain (such as with the Kaseya ransomware attack) and\r\nespionage. Throughout 2020, an operation attributed to the Foreign Intelligence Service of the Russian Federation\r\n(SVR) by the U.S. government was conducted to gain access to the update mechanism of the SolarWinds IT\r\nmanagement software and use it to broaden their intelligence collection capabilities. This activity is tracked by\r\nCrowdStrike as the StellarParticle campaign and is associated with the COZY BEAR adversary group. This blog\r\ndiscusses the novel tactics and techniques leveraged in StellarParticle investigations conducted by CrowdStrike.\r\nThese techniques include:\r\nCredential hopping for obscuring lateral movement\r\nOffice 365 (O365) Service Principal and Application hijacking, impersonation and manipulation\r\nStealing browser cookies for bypassing multifactor authentication\r\nUse of the TrailBlazer implant and the Linux variant of GoldMax malware\r\nCredential theft using Get-ADReplAccount\r\nCredential Hopping\r\nThe majority of StellarParticle-related investigations conducted by CrowdStrike have started with the\r\nidentification of adversary actions within a victim's O365 environment. This has been advantageous to\r\nCrowdStrike incident responders in that, through investigating victim O365 environments, they could gain an\r\naccurate accounting of time, account and source IP address of adversary victimization of the O365 tenant. In\r\nmultiple engagements, this led CrowdStrike incident responders to identify that the malicious authentications into\r\nvictim O365 tenants had originated from within the victim’s own network. Armed with this information,\r\nCrowdStrike investigators were able to identify from which systems in these internal networks the threat actor was\r\nmaking authentications to O365. These authentications would typically occur from servers in the environment,\r\nhttps://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/\r\nPage 1 of 19\n\nleading to natural investigative questions: Why would a user authenticate into O365 from a domain controller or\r\nother infrastructure server? What credentials were used as part of the session from which the O365 authentication\r\noccurred? This led our responders to identify the occurrence of “credential hopping,\" where the threat actor\r\nleveraged different credentials for each step while moving laterally through the victim's network. While this\r\nparticular technique is not necessarily unique to the StellarParticle campaign, it indicates a more advanced threat\r\nactor and may go unnoticed by a victim.\r\nBelow is an example of how a threat actor performs credential hopping:\r\nGain access to the victim's network by logging into a public-facing system via Secure Shell (SSH) using a\r\nlocal account \u003cuser sftp\u003e acquired during previous credential theft activities.\r\nUse port forwarding capabilities built into SSH on the public-facing system to establish a Remote Desktop\r\nProtocol (RDP) session to an internal server (Server 1) using a domain service account.\r\nFrom Server 1, establish another RDP session to a different internal server (Server 2) using a domain\r\nadministrator's account.\r\nLog in to O365 as a user with privileged access to cloud resources.\r\nFigure 1. Example of “credential hopping” technique\r\nThis technique could be hard to identify in environments where defenders have little visibility into identity usage.\r\nIn the example shown in Figure 1, the threat actor leveraged a service interactively, which should generate\r\ndetections for defenders to investigate. However, the threat actor could have easily used a second domain\r\nadministrator account or any other combination of accounts that would not be easily detected. A solution such as\r\nCrowdStrike Falcon® Identity Threat Detection would help identify these anomalous logons — and especially\r\ninfrequent destinations for accounts. (Read how CrowdStrike incident responders leverage the module in\r\ninvestigations in this blog: Credentials, Authentications and Hygiene: Supercharging Incident Response with\r\nFalcon Identity Threat Detection.) But how had the threat actor succeeded in authenticating into victim O365\r\ntenants, when multifactor authentication (MFA) had been enabled for every O365 user account at each victim\r\norganization investigated by CrowdStrike?\r\nCookie Theft to Bypass MFA\r\nEven though the victims required MFA to access cloud resources from all locations, including on premises, the\r\nthreat actor managed to bypass MFA through the theft of Chrome browser cookies. The threat actor accomplished\r\nthis by using administrative accounts to connect via SMB to targeted users, and then copy their Chrome profile\r\ndirectories as well as data protection API (DPAPI) data. In Windows, Chrome cookies and saved passwords are\r\nencrypted using DPAPI. The user-specific encryption keys for DPAPI are stored under C:\\Users\\\r\n\u003cuser\u003e\\AppData\\Roaming\\Microsoft\\Protect\\ . To leverage these encryption keys, the threat actor must first\r\ndecrypt them, either by using the user account’s Windows password, or, in Active Directory environments, by\r\nhttps://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/\r\nPage 2 of 19\n\nusing a DPAPI domain backup key that is stored on domain controllers. Once the threat actor had a Chrome\r\ncookies file from a user that had already passed an MFA challenge recently (for example, a timeout was 24 hours),\r\nthey decrypted the cookies file using the user’s DPAPI key. The cookies were then added to a new session using a\r\n“Cookie Editor” Chrome extension that the threat actor installed on victim systems and removed after using.\r\nShellbags, Falcon Telemetry and RDP Bitmap Cache\r\nFrom a forensic standpoint, the use of the Cookie Editor Chrome extension would have been challenging to\r\nidentify, due to the threat actor’s penchant for strict operational security. This activity was identified via a\r\nNewScriptWritten event within Falcon when a JavaScript file was written to disk by a threat actor-initiated\r\nChrome process. This event captured the unique extension ID associated with the extension, thereby allowing\r\nCrowdStrike incident responders to validate via the Chrome Store that the JavaScript file was associated with the\r\n“Cookie Editor” plugin. This extension permitted bypassing MFA requirements, as the cookies, replayed through\r\nthe Cookie Editor extension, allowed the threat actor to hijack the already MFA-approved session of a targeted\r\nuser. Shellbags were also instrumental in identifying the cookie theft activity. This artifact very clearly showed the\r\nthreat actor accessing targeted users’ machines in sequence and browsing to the Chrome and DPAPI directories\r\none after another. Parsing Shellbags for an administrative account leveraged by the threat actor resulted in entries\r\nsimilar to the below.\r\nFigure\r\n2. Shellbag artifacts showing targeting of Chrome directories\r\nCrowdStrike identified forensic evidence that showed the entire attack path: browsing to a target user’s Chrome\r\nand DPAPI directories via administrative share, installing the Cookie Editor extension, and using Chrome to\r\nimpersonate the targeted user in the victim’s cloud tenants. The decryption of the cookies is believed to have taken\r\nplace offline after exfiltrating the data via the clipboard in the threat actor’s RDP session.\r\nhttps://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/\r\nPage 3 of 19\n\nFigure 3. Representation of lateral movement to cookie theft to O365 authentication\r\nCrowdStrike identified a similar TTP where the threat actor connected via RDP to a user’s workstation with the\r\nworkstation owner’s account (e.g., connecting via RDP to user1-pc using the account user1). In cases where the\r\nuser had only locked their screen and not signed out, the threat actor was able to take over the user’s Windows\r\nsession, as the RDP session would connect to the existing session of the same user. By examining RDP Bitmap\r\nCache files, CrowdStrike was able to demonstrate that the threat actor had opened Chrome and exported all of the\r\nuser’s saved passwords as plaintext in a CSV file during these sessions.\r\nFigure 4. RDP Bitmap Cache\r\nreconstruction showing exportation of Chrome passwords\r\nIn addition, the threat actor visited sensitive websites that the user had access to, which in one instance allowed\r\nthem to browse and download a victim’s customer list. After this, the threat actor navigated to the user’s Chrome\r\nhistory page and deleted the specific history items related to threat actor activity, leaving the rest of the user’s\r\nChrome history intact.\r\nhttps://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/\r\nPage 4 of 19\n\nO365 Delegated Administrator Abuse\r\nCrowdStrike also identified a connection between StellarParticle-related campaigns and the abuse of Microsoft\r\nCloud Solution Partners’ O365 tenants. This threat actor abused access to accounts in the Cloud Solution Partner’s\r\nenvironment with legitimate delegated administrative privileges to then gain access to several customers’ O365\r\nenvironments. By analyzing Azure AD sign-ins, CrowdStrike was able to use known indicators of compromise\r\n(IOCs) to identify several threat actor logins to customer environments. These cross-tenant sign-ins were\r\nidentified by looking for values in the resourceTenantId attribute that did not match the Cloud Solution\r\nPartner’s own Azure tenant ID. CrowdStrike also identified a limitation within Microsoft’s Delegated\r\nAdministration capabilities for Microsoft Cloud Solution Partners. While a normal O365 administrator can be\r\nprovided dozens of specific administrative roles to limit the privileges granted, this same degree of customization\r\ncannot be applied to Microsoft Cloud Solution Partners that use the delegated administrator functionality in O365.\r\nFor Microsoft Cloud Solution Partners, there are only two substantial administrative options today when\r\nmanaging a customer’s environment, Admin agent or Helpdesk agent .\r\n2\r\n The Helpdesk agent role provides\r\nvery limited access that is equivalent to a password admin role, whereas the Admin agent role provides broad\r\naccess more equivalent to global administrator. This limitation is scheduled to be resolved in 2022 via Microsoft’s\r\nscheduled feature, Granular Delegated Admin Privileges (GDAP).3\r\nUser Access Logging (UAL)\r\nThe Windows User Access Logging (UAL) database is an extremely powerful artifact that has played an\r\ninstrumental role in the investigation of StellarParticle-linked cases. In particular, UAL has helped our responders\r\nidentify earlier malicious account usage that ultimately led to the identification of the aforementioned TrailBlazer\r\nimplant and Linux version of the GoldMax variant.\r\nThe UAL database is available by default on Server editions of Windows starting with Server 2012. This database\r\nstores historical information on user access to various services (or in Windows parlance, Roles) on the server for\r\nup to three years (three years minus one day) by default. UAL contains information on the type of service\r\naccessed, the user that accessed the service and the source IP address from which the access occurred. One of the\r\nmost useful roles recorded by UAL is the File Server role, which includes SMB access, though other role types\r\ncan also be very helpful. An overview of UAL, what information it contains and how it can be leveraged in\r\nforensic investigations can be found here. In multiple StellarParticle-related cases, because the threat actor used\r\nthe same set of accounts during their operations in the environment, CrowdStrike was able to identify previous\r\nmalicious activity going back multiple years, based solely on UAL data. Even though it’s only available on Server\r\n2012 and up, UAL can still be used to trace evidence of threat actor activity on legacy systems as long as the\r\nactivity on the legacy system involves some (deliberate or unintentional) access to a 2012+ system. For example,\r\nin addition to tracking SMB activity, UAL databases on Domain Controllers track Active Directory access. This\r\nallowed CrowdStrike to demonstrate that a given user account was also authenticating to Active Directory from a\r\ngiven source IP address two years prior. Because the user account was known to have recently been abused by the\r\nthreat actor, and the source IP of the system in question was not one that account would typically be active on, the\r\ninvestigation led to the source system and ultimately resulted in the timeline of malicious activity being pushed\r\nback by years, with additional compromised systems even being discovered still running unique malware from\r\nthat time period.\r\nhttps://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/\r\nPage 5 of 19\n\nTrailBlazer and GoldMax\r\nThroughout StellarParticle-related investigations, CrowdStrike has identified two sophisticated malware families\r\nthat were placed on victim systems in the mid-2019 timeframe: a Linux variant of GoldMax and a completely new\r\nfamily CrowdStrike refers to as TrailBlazer.\r\nTrailBlazer\r\nAttempted to blend in with a file name that matched the system name it resided on\r\nConfigured for WMI persistence (generally uncommon in 2019)\r\nUsed likely compromised infrastructure for C2\r\nMasquerades its command-and-control (C2) traffic as legitimate Google Notifications HTTP requests\r\nTrailBlazer is a sophisticated malware family that provides modular functionality and a very low prevalence. The\r\nmalware shares high-level functionality with other malware families. In particular, the use of random identifier\r\nstrings for C2 operations and result codes, and attempts to hide C2 communications in seemingly legitimate web\r\ntraffic, were previously observed tactics, techniques and procedures (TTPs) in GoldMax and SUNBURST.\r\nTrailBlazer persists on a compromised host using WMI event subscriptions4 — a technique also used by SeaDuke\r\n— although this persistence mechanism is not exclusive to COZY BEAR.5\r\nWMI event filter\r\nSELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE\r\nTargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System' AND\r\nTargetInstance.SystemUpTime \u003e= 180 AND TargetInstance.SystemUpTime \u003c\r\n480\r\nWMI Event consumer\r\n(CommandLineTemplate)\r\nC:\\Program Files (x86)\\Common Files\\Adobe\\\u003cFILENAME\u003e.exe\r\nFilter to consumer\r\nbinding\r\nCommandLineEventConsumer.Name=\"\u003cGUID1\u003e\"|__EventFilter.Name=\"\r\n\u003cGUID2\u003e\"\r\nTable 1. TrailBlazer WMI Persistence\r\nIn the obfuscated example above, TrailBlazer ( \u003cFILENAME\u003e .exe ) would be executed when the system's uptime\r\nwas between 180 and 480 seconds.\r\nGoldMax (Linux variant)\r\nAttempted to blend in with a file name that matched the system name it resided on\r\nConfigured for persistence via a crontab entry with a @reboot line\r\nUsed likely compromised infrastructure for C2\r\nGoldMax was first observed during post-exploitation activity in the campaign leveraging the SolarWinds supply\r\nchain attacks. Previously identified samples of GoldMax were built for the Windows platform, with the earliest\r\nidentified timestamp indicating a compilation in May 2020, but a recent CrowdStrike investigation discovered a\r\nhttps://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/\r\nPage 6 of 19\n\nGoldMax variant built for the Linux platform that the threat actor deployed in mid-2019. This variant extends\r\nthe backdoor’s known history and shows that the threat actor has used the malware in post-exploitation\r\nactivity targeting other platforms than Windows. The 2019 Linux variant of the GoldMax backdoor is almost\r\nidentical in functionality and implementation to the previously identified May 2020 Windows variant. The very\r\nfew additions to the backdoor between 2019 and 2020 likely reflect its maturity and longstanding evasion of\r\ndetections. It is likely GoldMax has been used as a long-term persistence backdoor during StellarParticle-related\r\ncompromises, which would be consistent with the few changes made to the malware to modify existing functions\r\nor support additional functionality. Persistence was established via a crontab entry for a non-root user. With the\r\nbinary named to masquerade as a legitimate file on the system and placed in a hidden directory, a crontab entry\r\nwas created with a @reboot line so the GoldMax binary would execute again upon system reboot. Additionally,\r\nthe threat actor used the nohup command to ignore any hangup signals, and the process will continue to run even\r\nif the terminal session was terminated.\r\nFigure\r\n5. Crontab entry for GoldMax persistence\r\nEnumeration Tools/Unique Directory Structure\r\nThroughout our StellarParticle investigations, CrowdStrike identified what appeared to be a VBScript-based\r\nActive Directory enumeration toolkit. While the script’s contents have not been recovered to date, CrowdStrike\r\nhas observed identical artifacts across multiple StellarParticle engagements that suggest the same or similar tool\r\nwas used.\r\nIn each instance the tool was used, Shellbags data indicated that directories with random names of a consistent\r\nlength were navigated to by the same user that ran the tool. After two levels of randomly named directories,\r\nShellbags proved the existence of subdirectories named after the FQDNs for the victims’ various domains. In\r\naddition, the randomly named directories are typically created in a previously existing directory that’s one level\r\noff of the root of the C drive. The randomly named directories have a consistent length where the first directory is\r\nsix characters and the next directory is three characters. To date, the names of the directories have always been\r\nformed from lowercase alphanumeric characters. For example, Shellbags indicated that directories matching the\r\nnaming patterns below were browsed to (where “XX” is a previously existing directory on the system):\r\nC:\\XX\\{6}\r\nC:\\XX\\{6}\\{3}\r\nC:\\XX\\{6}\\{3}\\domain.FQDN\r\nC:\\XX\\{6}\\{3}\\domain-2.FQDN\r\nIn each case, immediately prior to the creation of the directories referenced above, there was evidence of\r\nexecution of a VBScript file by the same user that browsed to the directories. This evidence typically came from a\r\nUserAssist entry for wscript.exe, as well as RecentApps entries for wscript.exe (that would also include the\r\nVBScript filename). In addition, the Jump List for wscript.exe contained evidence of the VBScript files. The name\r\nof the VBScript files varied across engagements and was generally designed to look fairly innocuous and blend in.\r\nTwo examples are env.vbs and WinNet.vbs . Due to the subdirectories that are named after the FQDNs for\r\nhttps://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/\r\nPage 7 of 19\n\nvictim domains, CrowdStrike assesses with moderate confidence that the scripts represent an AD enumeration tool\r\nused by the adversary.\r\nInternal Wiki Access\r\nAcross multiple StellarParticle investigations, CrowdStrike identified unique reconnaissance activities performed\r\nby the threat actor: access of victims' internal knowledge repositories.6 Wikis are commonly used across industries\r\nto facilitate knowledge sharing and as a source of reference for a variety of topics. While operating in the victim's\r\ninternal network, the threat actor accessed sensitive information specific to the products and services that the\r\nvictim organization provided. This information included items such as product/service architecture and design\r\ndocuments, vulnerabilities and step-by-step instructions to perform various tasks. Additionally, the threat actor\r\nviewed pages related to internal business operations such as development schedules and points of contact. In some\r\ninstances these points of contact were subsequently targeted for further data collection. The threat actor's wiki\r\naccess could be considered an extension of \"Credential Hopping\" described earlier. The threat actor established\r\nRDP sessions to internal servers using privileged accounts and then accessed the wiki using a different set of\r\ncredentials. CrowdStrike observed the threat actor accessing the wiki as users who would be considered \"non-privileged\" from an Active Directory perspective but had access to sensitive data specific to the victim's products\r\nor services. At this time, the malicious access of internal wikis is an information gathering technique that\r\nCrowdStrike has only observed in StellarParticle investigations. CrowdStrike was able to identify the wiki access\r\nprimarily through forensic analysis of the internal systems used by the threat actor. Given the threat actor's\r\npenchant for clearing browser data, organizations should not rely upon the availability of these artifacts for future\r\ninvestigations. CrowdStrike recommends the following best practices for internal information repositories:\r\nEnable detailed access logging\r\nEnsure logs are centralized and stored for at least 180 days\r\nCreate detections for anomalous activity such as access from an unusual location like a server subnet\r\nEnable MFA on the repository site, or provide access via Single Sign On (SSO) behind MFA\r\nO365 Built-in Service Principal Hijacking\r\nThe threat actor connected via Remote Desktop from a Domain Controller to a vCenter server and opened a\r\nPowerShell console, then used the PowerShell command -ep bypass to circumvent the execution policy. Using\r\nthe Windows Azure Active Directory PowerShell Module, the threat actor connected to the victim’s O365 tenant\r\nand began performing enumeration queries. These queries were recorded in text-based logs that existed under the\r\npath C:\\Users\\\u003cuser\u003e\\AppData\\Local\\Microsoft\\Office365\\Powershell\\ . Similar logs (for Azure AD instead of\r\nO365) can be found under the path: C:\\Users\\\u003cuser\u003e\\AppData\\Local\\Microsoft\\AzureAD\\Powershell\\ . While\r\nthe logs didn’t include what data was returned by the queries, they did provide some insight such as the user\r\naccount used to connect to the victim’s O365 tenant (which was not the same as the user the threat actor used to\r\nRDP to the vCenter server). The logs contained commands issued and the count of the results returned for a\r\nspecific command. The commands included enumeration queries such as:\r\nListAccountSkus\r\nListPartnerContracts\r\nListServicePrincipals\r\nhttps://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/\r\nPage 8 of 19\n\nListServicePrincipalCredentials\r\nListRoles\r\nListRoleMembers\r\nListUsers\r\nListDomains\r\nGetRoleMember\r\nGetPartnerInformation\r\nGetCompanyInformation\r\nIn this case, however, the most significant and concerning log entry was one that indicated the command\r\nAddServicePrincipalCredentials was executed. By taking the timestamp that the command was executed via\r\nthe PowerShell logs on the local system, CrowdStrike analyzed the configuration settings in the victim’s O365\r\ntenant and discovered that a new secret had been added to a built-in Microsoft Azure AD Enterprise Application,\r\nMicrosoft StaffHub Service Principal, which had Application level permissions. Further, the newly added\r\nsecret was set to remain valid for more than a decade. This data was acquired by exporting the secrets and\r\ncertificates details for each Azure AD Enterprise Application. The Service Principal (now renamed to Microsoft\r\nTeams Shifts ) had the following permissions at the time the configuration settings were collected:\r\nMember.Read\r\nMember.Read.All\r\nMember.ReadWrite\r\nMember.ReadWrite.All\r\nShift.Read\r\nShift.Read.All\r\nShift.ReadWrite\r\nShift.ReadWrite.All\r\nTeam.Read\r\nTeam.Read.All\r\nTeam.ReadWrite\r\nTeam.ReadWrite.All\r\nUser.Read.All\r\nUser.ReadWrite.All\r\nWebHook.Read.All\r\nWebHook.ReadWrite.All\r\nCrowdStrike was unable to find Microsoft documentation, but based on open-source research,7 this application\r\nlikely had the following permissions around the time of registration:\r\nMail.Read\r\nGroup.Read.All\r\nFiles.Read.All\r\nGroup.ReadWrite.All\r\nhttps://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/\r\nPage 9 of 19\n\nThe most notable permissions above are the Mail.Read , Files.Read and Member.ReadWrite\r\npermissions.\r\nThese permissions would allow the threat actor to use the Microsoft Staffhub service principal to read all mail\r\nand SharePoint/OneDrive files in the organization, as well as create new accounts and assign administrator\r\nprivileges to any account in the organization.\r\nBy running the commands from within the victim’s environment, MFA requirements were bypassed due to\r\nconditional access policies not covering Service Principal sign-ins at this point of time.8 However, as explained\r\nearlier, the threat actor managed to continue to access the victim’s cloud environment even when the victim\r\nenforced MFA for all connections regardless of source. While the bulk of the evidence for this activity came from\r\nthe text-based O365 PowerShell logs, the NTUSER.DAT registry hive for the user that was running the PowerShell\r\ncmdlets also included information on the accounts that were used to authenticate to the cloud. This information\r\nwas stored under the registry path. Below is an example of the registry data:\r\nFigure\r\n6. Example registry entry showing target O365 email accounts\r\nThe same WSMan connection string was also located in the user’s NTUSER.DAT registry hive under the path:\r\nFigure\r\n7. WSMan connection string registry location\r\nWhile not strictly related to the O365 PowerShell activity, the Windows Event Log Microsoft-Windows-WinRM%4Operational.evtx also included information on connection attempts made to external O365 tenants. This\r\ninformation was logged under Event ID 6. Below is an example of what the event included:\r\nFigure\r\n8. Windows Event Log entry showing connection to O365 tenants\r\nO365 Company Service Principal Manipulation\r\nThe threat actor also deployed several layers of persistence utilizing both pre-existing and threat actor-created\r\nService Principals with the ultimate goal of gaining global access to email.\r\nAttacker-created Service Principal\r\nFirst, the threat actor used a compromised O365 administrator account to create a new Service Principal with a\r\ngeneric name. This Service Principal was granted company administrator privileges. From there, the threat\r\nactor added a credential to this Service Principal so that they could access the Service Principal directly, without\r\nuse of an O365 user account. These actions were recorded in Unified Audit Logs with the following three\r\noperation names:\r\nhttps://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/\r\nPage 10 of 19\n\nAdd service principal\r\nAdd member to role\r\nAdd service principal credentials.\r\nUpdate Service Principal\r\nCompany-Created Service Principal Hijacking\r\nNext, the threat actor utilized the threat actor-created Service Principal to take control of a second Service\r\nPrincipal. This was done by adding credentials to this second Service Principal, which was legitimately created by\r\nthe company. This now compromised company-created Service Principal had mail.read graph permissions\r\nconsented on behalf of all users within the tenant. This action was recorded by just one operation type in Unified\r\nAudit Logs. This operation type is named Add service principal credentials .\r\nMail.Read Service Principal Abuse\r\nFinally, the threat actor utilized the compromised Service Principal with the assigned  mail.read permissions to\r\nthen read emails of several different users in the company’s environment. CrowdStrike was able to use the Unified\r\nAudit Logs’ (UAL) MailItemsAccessed operation events to see the exact emails the threat actor viewed, as the\r\nmajority of the users in the tenant were assigned O365 E5 licenses. When performing analysis on the UAL,\r\nCrowdStrike used the ClientAppId value within the MailItemsAccessed operation and cross-correlated with\r\nthe Application ID of the compromised service principal to see what activities were performed by the threat actor.\r\nO365 Application Impersonation\r\nAnother consistent TTP identified during StellarParticle investigations has been the abuse of the\r\nApplicationImpersonation\r\n9\r\n role. When this role was assigned to a particular user that was controlled by the\r\nthreat actor, it allowed the threat actor to impersonate any user within the O365 environment. These impersonated\r\nevents are not logged verbosely by the Unified Audit Logs and can be difficult to detect. While the assignment of\r\nthese ApplicationImpersonation roles were not logged in the Unified Audit Logs, CrowdStrike was able to\r\nidentify this persistence mechanism via the management role configuration settings, which can be exported with\r\nthe Exchange PowerShell command: Get-ManagementRoleAssignment -Role ApplicationImpersonation .\r\nCrowdStrike then analyzed the exported configuration settings and identified several users (not service accounts)\r\nthat the threat actor likely gave direct ApplicationImpersonation roles during the known periods of\r\ncompromise.\r\nRemote Tasklist\r\nThe threat actor attempted to remotely list running processes on systems using tasklist.exe . As tasklist uses\r\nWMI “under the hood,” this activity was captured by Falcon as SuspiciousWmiQuery events that included the\r\nquery and the source system. Additionally, the failed (not successful) process listing resulted in a DCOM error that\r\nwas logged in the System.evtx event log under Event ID 10028. A sample of the information included with this\r\nevent is below:\r\nhttps://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/\r\nPage 11 of 19\n\nFigure\r\n9. Event ID 10028 showing failed execution of remote tasklist\r\nThis remote process listing was consistently used by the threat actor targeting the same or similar lists of remote\r\nsystems, and the owners of the targeted systems also happened to be the individuals with cloud access that the\r\nthreat actor was interested in. While unproven, it’s possible the threat actor was running tasklist remotely on\r\nthese systems specifically to see which of the target systems was running Google Chrome. This is because a\r\ncurrent or recent Chrome session to the victim’s cloud tenants would be potentially beneficial in the hijacking of\r\nsessions that the threat actor performed in order to access the victim’s cloud resources.\r\nFTP Scanning/Identity Knowledge\r\nIn one instance, after being evicted from a victim environment, the threat actor began probing external services as\r\na means to regain access, initially focusing on (S)FTP servers that were internet-accessible. Logs on the servers\r\nindicated that the threat actor attempted to log in with multiple valid accounts and in several cases was successful.\r\nThere was little to no activity during the (S)FTP sessions. This likely was an exercise in attempting to identify\r\nmisconfigured (S)FTP accounts that also had shell access, similar to what’s described in the Credential Hopping\r\nsection earlier. Some of the accounts used were not in the victim’s Active Directory, as these were accounts for\r\ncustomers of the victim and stored in a separate LDAP database. However, the threat actor had knowledge of these\r\naccounts and used them on the correct systems, which further confirmed that the threat actor had advanced\r\nknowledge of the victim’s environment.\r\nAfter confirming the FTP accounts did not provide shell access into the environment, the threat actor began\r\nattempting to connect into the environment via VPN. The threat actor attempted to log in to the VPN using several\r\nuser accounts but was prevented from connecting, either due to not having the correct password, or due to having\r\nthe correct password but not getting past the recently implemented MFA requirement. Eventually, the threat actor\r\nattempted an account that they had the correct password for but that had not been set up with MFA. This resulted\r\nin a prompt being displayed to the threat actor that included an MFA setup link. The threat actor subsequently set\r\nup MFA for the account and successfully connected to the victim’s network via VPN.\r\nTA Masquerading of System Names\r\nDuring the attempted and successful VPN authentications described above, the threat actor ensured the hostname\r\nof their system matched the naming convention of hostnames in the victim’s environment. This again showed a\r\nstrong knowledge of the victim’s internal environment on the part of the threat actor. Not only did the\r\nmasqueraded hostnames follow the correct naming convention from a broad perspective, they were also valid in\r\nterms of what would be expected for the user account the threat actor leveraged (i.e., in terms of the site name and\r\nasset type indicated in the hostname). This masqueraded hostname technique has been observed at multiple\r\nStellarParticle-related investigations.\r\nCredential Theft Using Get-ADReplAccount\r\nhttps://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/\r\nPage 12 of 19\n\nIn one example, the threat actor connected into the victim’s environment via a VPN endpoint that did not have\r\nMFA enabled. Once connected to the VPN, the threat actor connected via Remote Desktop to a Domain Controller\r\nand copied the DSInternals10 PowerShell module to the system. The threat actor subsequently ran the DSInternals\r\ncommand Get-ADReplAccount targeting two of the victim’s domains. This command uses the Microsoft\r\nDirectory Replication Service (MS-DRSR) protocol and specifically the IDL_DRSGetNCChanges method to\r\nreturn account information from Active Directory such as the current NTLM password hashes and previous\r\npassword hashes used for enforcing password reuse restrictions. A common name for this particular technique is\r\nDCSync.11\r\n An example output from Get-AdReplAccount is below:\r\nDistinguishedName: CN=TestUser,OU=Admins,OU=Users,DC=demo,DC=local\r\nSid: S-1-5-21-1432446722-301123485-1266542393-2012\r\nGuid: 12321930-7c05-4011-8a3e-e0b9b6e04567\r\nSamAccountName: TestUser\r\nSamAccountType: User\r\nUserPrincipalName: TestUser@demo.local\r\nPrimaryGroupId: 513\r\nSidHistory:\r\nEnabled: True\r\nUserAccountControl: NormalAccount\r\nAdminCount: True\r\nDeleted: False\r\nLastLogonDate: 12/2/2021 1:41:46 PM\r\nDisplayName: TestUser\r\nGivenName: Test\r\nSurname: User\r\nDescription: Admin Account\r\nServicePrincipalName:\r\nSecurityDescriptor: DiscretionaryAclPresent, SystemAclPresent, DiscretionaryAclAutoInherited, SystemAclAutoInher\r\nOwner: S-1-5-21-1432446722-301123485-1266542393-512\r\nSecrets\r\n NTHash: 84a058676bb6d7de4237e18f09b91156\r\n LMHash:\r\n NTHashHistory:\r\n Hash 01: 84a058676bb6d7de4237e18f09b91156\r\n Hash 02: e047ebb3b7c463928c928fca95ac0ac8\r\n Hash 03: 6dc3cdb3e559ef00d3521351ace7477e\r\n Hash 04: a88355849f35fe7336de23a4ca3e6a9e\r\n Hash 05: de9bde95677672295349aa6e1e857704\r\n LMHashHistory:\r\n Hash 01: 12227358dd7013c7dbdbd8fdcc0c6668\r\n Hash 02: 6a028636a6f52491424586bb88357f7c\r\n Hash 03: c13ef7347853dc3be7e7259fdc8818a1\r\n Hash 04: 6635151746869ce485246037747adae1\r\n Hash 05: 85543f498b007e07a3da662c8a9d450b\r\n SupplementalCredentials:\r\n ClearText:\r\nhttps://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/\r\nPage 13 of 19\n\nNTLMStrongHash: de164e3465f163e846a5e1c22a5ac649\r\n Kerberos:\r\n Credentials:\r\n DES_CBC_MD5\r\n Key: 0013364f00003915\r\n DES_CBC_CRC\r\n Key: 0013364f00003915\r\n OldCredentials:\r\n DES_CBC_MD5\r\n Key: 00002a46000004bc\r\n DES_CBC_CRC\r\n Key: 00002a46000004bc\r\n Salt: demo.localTestUser\r\n Flags: 0\r\n KerberosNew:\r\n Credentials:\r\n AES256_CTS_HMAC_SHA1_96\r\n Key: afd4d60e8d0920bc2f94d551f62f0ea2a17523bf2ff8ffb0fdade2a90389282f\r\n Iterations: 4096\r\n AES128_CTS_HMAC_SHA1_96\r\n Key: f67c2bcbfcfa30fccb36f72dca22a817\r\n Iterations: 4096\r\n DES_CBC_MD5\r\n Key: 00002f34000004ee\r\n Iterations: 4096\r\n DES_CBC_CRC\r\n Key: 00002f34000004ee\r\n Iterations: 4096\r\n OldCredentials:\r\n AES256_CTS_HMAC_SHA1_96\r\n Key: b430783ab4c957cf6a03d3d348af27264c0d872932650ffca712d9ebcf778b9f\r\n Iterations: 4096\r\n AES128_CTS_HMAC_SHA1_96\r\n Key: dc34bfd5e469edbeada77fac56aa35ae\r\n Iterations: 4096\r\n DES_CBC_MD5\r\n Key: 0000345400000520\r\n Iterations: 4096\r\n DES_CBC_CRC\r\n Key: 0000345400000520\r\n Iterations: 4096\r\n OlderCredentials:\r\n AES256_CTS_HMAC_SHA1_96\r\n Key: 26efd3593712e555f8366bb4b8aff097d09acd93c3a1b6d4ea03c578aad9e087\r\n Iterations: 4096\r\n AES128_CTS_HMAC_SHA1_96\r\n Key: c38dfbd6c00b5f3b010a07f9e824fc38\r\nhttps://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/\r\nPage 14 of 19\n\nIterations: 4096\r\n DES_CBC_MD5\r\n Key: 000039a500000551\r\n Iterations: 4096\r\n DES_CBC_CRC\r\n Key: 000039a500000551\r\n Iterations: 4096\r\n ServiceCredentials:\r\n Salt: demo.localTestUser\r\n DefaultIterationCount: 4096\r\n Flags: 0\r\n WDigest:\r\n Hash 01: 83ed141ab0eaf1ff7694147ba97e1994\r\n Hash 02: e73a8c05d4a7df53774bfa7ef8f0f574\r\n Hash 03: 0c228c5816a79e561d999d489499a12a\r\n Hash 04: 83ed141ab0eaf1ff7694147ba97e1994\r\n Hash 05: e73a8c05d4a7df53774bfa7ef8f0f574\r\n Hash 06: 4e7c5ec6ffb6100f0c7f0bc57749bc93\r\n Hash 07: 83ed141ab0eaf1ff7694147ba97e1994\r\n Hash 08: 10265b08a3bb710da516832eaf64368a\r\n Hash 09: 10265b08a3bb710da516832eaf64368a\r\nKey Credentials:\r\nCredential Roaming\r\n Created:\r\n Modified:\r\n Credentials:\r\nFigure 10. Get-ADReplAccount example output\r\nWhen executing the Get-ADReplAccount command, the threat actor specified the AD context to be targeted via\r\nthe NamingContext parameter. This was necessary, as the threat actor was targeting multiple domains. The\r\nresulting output of each command was redirected to a text file and compressed as zip archives before exfiltration.\r\nThe fact that Get-ADReplAccount command includes not only the current NTLM hashes but also the hash history\r\n(i.e., hashes of previous passwords used by a user account) meant that the threat actor also had the ability to\r\ndiscover accounts that either reused the same passwords or used similar passwords when the account password\r\nwas changed.\r\nCredential Refresh\r\nOn some investigations, the dwell time of the threat actor spanned years. Given this extended period, it is logical\r\nto assume that some credentials obtained by the threat actor would be rotated during normal business operations.\r\nTo combat this, the threat actor periodically \"refreshed\" their credential set by performing credential theft\r\nactivities in an already compromised environment. At one victim, CrowdStrike identified multiple instances of\r\ndomain credential theft months apart, each time with a different credential theft technique.\r\nhttps://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/\r\nPage 15 of 19\n\nOne of the credential theft techniques identified by CrowdStrike was the use of a PowerShell script to execute\r\nMimikatz in-memory. While in-memory Mimikatz is not particularly unique, the script executed by the threat\r\nactor was heavily obfuscated and encrypted the output using AES256. CrowdStrike was able to reconstruct the\r\nPowerShell script from the PowerShell Operational event log as the script's execution was logged automatically\r\ndue to the use of specific keywords. CrowdStrike recommends that organizations upgrade PowerShell on their\r\nsystems, as this functionality is only available with PowerShell version 5 and above. In addition to refreshing the\r\nthreat actor's credentials, the threat actor would also refresh their understanding of the victim's AD environment.\r\nAround the time when the threat actor executed Get-ADReplAccount , the threat actor also executed a renamed\r\nversion of AdFind to output domain reconnaissance information. In this instance, AdFind was renamed to\r\nmasquerade as a legitimate Windows binary. The usage of renamed AdFind is consistent with other industry\r\nreporting on this campaign.\r\nIn addition to using scripted commands, operators were repeatedly observed manually executing several standard\r\nPowerShell cmdlets to enumerate network information from AD, including Get-ADUser and Get-ADGroupMember to query specific members in the directory. This information provided the adversary with a list of\r\naccounts possessing particular privileges — in this case, the ability to make VPN connections — that would be\r\nsubject to later credential stealing attempts and leveraged to access the victim at a later time.\r\nPassword Policies/Hygiene\r\nIn some cases, the threat actor was able to quickly return to the environment and essentially pick up where they\r\nleft off, even though the organization had performed an enterprise-wide password reset, including a reset of all\r\nservice accounts and the double-reset of the krbtgt account. CrowdStrike determined that in these cases,\r\nadministrative users had “reset” their own password to the same password they previously used, essentially\r\nnullifying the impact of the enterprise-wide reset. This was possible even though the customer’s Active Directory\r\nwas configured to require new passwords to be different from the previous five passwords for a given account.\r\nUnfortunately, this check only applies when a user is changing their password via the “password change” method\r\n— but if a “password reset” is performed (changing the password without knowing the previous password), this\r\ncheck is bypassed for an administrative user or a Windows account that has the Reset Password permission on a\r\nuser’s account object.12 Since the Get-ADReplAccount cmdlet described above included the NTHashHistory\r\nvalues (i.e., previous password hashes) for user accounts, CrowdStrike was able to verify that some administrative\r\naccounts indeed had the exact same password hash showing up multiple times in the password history, as well as\r\nin the current NTHash value.\r\nClose Out\r\nThe StellarParticle campaign, associated with the COZY BEAR adversary group, demonstrates this threat actor’s\r\nextensive knowledge of Windows and Linux operating systems, Microsoft Azure, O365, and Active Directory, and\r\ntheir patience and covert skill set to stay undetected for months — and in some cases, years.\r\nA special thank you to the CrowdStrike Incident Response and CrowdStrike Intelligence teams for helping make\r\nthis blog possible, especially Ryan McCombs, Ian Barton, Patrick Bennet, Alex Parsons, Christopher Romano,\r\nJackson Roussin and Tom Goldsmith.\r\nhttps://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/\r\nPage 16 of 19\n\nEndnotes\r\n1. https://us-cert.cisa.gov/sites/default/files/publications/CISA_Fact_Sheet-Russian_SVR_Activities_Related_to_SolarWinds_Compromise_508C.pdf\r\n2. https://docs.microsoft.com/en-us/partner-center/permissions-overview\r\n3. https://docs.microsoft.com/en-us/partner-center/announcements/2021-december#9\r\n4. https://attack.mitre.org/techniques/T1546/003/\r\n5. CrowdStrike Premium Intelligence Report\r\n6. https://attack.mitre.org/techniques/T1213/001/\r\n7. https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/\r\n8. https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/block-legacy-authentication\r\n9. https://docs.microsoft.com/en-us/exchange/applicationimpersonation-role-exchange-2013-help\r\n10. https://github.com/MichaelGrafnetter/DSInternals\r\n11. https://attack.mitre.org/techniques/T1003/006/\r\n12. https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-samr/bbee5135-3db2-4824-873a-55104c3610ad\r\nMITRE ATT\u0026CK Framework\r\nThe following table maps TTPs covered in this article to the MITRE ATT\u0026CK® framework.\r\nTactic Technique Observable\r\nCredential Access\r\nT1003.006 OS Credential\r\nDumping: DCSync\r\nThe threat actor obtained Active Directory credentials\r\nthrough domain replication protocols using the Get-ADReplAccount command from DSInternals\r\nCredential Access\r\nT1003.001: OS Credential\r\nDumping: LSASS Memory\r\nThe threat actor used a heavily obfuscated PowerShell\r\nscript to execute the Mimikatz commands\r\n'privilege::debug sekurlsa::logonpasswords\r\n\"lsadump::lsa /patch\"' in-memory and encrypt the output\r\nInitial Access /\r\nPersistence\r\nT1078.003: Valid Accounts:\r\nLocal Accounts\r\nA local account was used by the Threat Actor to\r\nestablish a SSH tunnel into the internal network\r\nenvironment\r\nInitial Access /\r\nPersistence\r\nT1133: External Remote\r\nServices\r\nThe threat actor used VPNs to gain access to systems\r\nand persist in the environment\r\nCredential Access\r\nT1555.003: Credentials\r\nfrom Password Stores:\r\nCredentials from Web\r\nBrowsers\r\nThe threat actor exported saved passwords from user's\r\nChrome browser installations\r\nhttps://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/\r\nPage 17 of 19\n\nCredential Access\r\nT1539: Steal Web Session\r\nCookie\r\nThe threat actor stole web session cookies from end user\r\nworkstations and used them to access cloud resources\r\nLateral\r\nMovement\r\nT1021.001: Remote\r\nServices: Remote Desktop\r\nProtocol\r\nThe threat actor used both privileged and non-privileged\r\naccounts for RDP throughout the environment,\r\ndepending on the target system\r\nInitial Access,\r\nPersistence\r\nT1078.004: Valid Accounts:\r\nCloud Accounts\r\nThe threat actor used accounts with Delegated\r\nAdministrator rights to access other O365 tenants. The\r\nThreat actor also used valid accounts to create\r\npersistence within the environment.\r\nPersistence\r\nT1546.003: Event\r\nTriggered Execution:\r\nWindows Management\r\nInstrumentation Event\r\nSubscription\r\nTrailBlazer was configured to execute after a reboot via\r\na command-line event consumer\r\nDefense Evasion\r\nT1036.005: Masquerading:\r\nMatch Legitimate Name or\r\nLocation\r\nThe threat actor renamed their utilities to masquerade as\r\nlegitimate system binaries (AdFind as svchost.exe),\r\nmatch the system's role (GoldMax), or appear legitimate\r\n(TrailBlazer as an apparent Adobe utility). Additionally,\r\nthe threat actor renamed their systems prior to\r\nconnecting to victim's VPNs to match the victim's\r\nsystem naming convention\r\nDiscovery\r\nT1087.002: Account\r\nDiscovery: Domain\r\nAccount T1482: Domain\r\nTrust Discovery\r\nT1069.002: Permission\r\nGroups Discovery: Domain\r\nGroups\r\nThe threat actor used AdFind, standard PowerShell\r\ncmdlets, and custom tooling to identify various pieces of\r\ninformation from Active Directory\r\nDefense Evasion\r\n/ Lateral\r\nMovement\r\nT1550.001: Use Alternate\r\nAuthentication Material:\r\nApplication Access Token\r\nThe threat actor used compromised service principals to\r\nmake changes to the Office 365 environment.\r\nCollection\r\nT1213.: Data from\r\nInformation Repositories:\r\nThe threat actor accessed data from Information\r\nRepositories\r\nPersistence\r\nT1098.001: Account\r\nManipulation: Additional\r\nCloud Credentials\r\nThe threat actor added credentials to O365 Service\r\nPrincipals\r\nhttps://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/\r\nPage 18 of 19\n\nPersistence\r\nT1078.004: Valid Accounts:\r\nCloud Accounts\r\nThe threat actor created new O365 Service Principals to\r\nmaintain access to victim's environments\r\nDiscovery T1057: Process Discovery\r\nThe threat actor regularly interrogated other systems\r\nusing tasklist.exe\r\nReconnaissance\r\nT1595.001: Active\r\nScanning: Scanning IP\r\nBlocks\r\nThe threat actor probed external services in an attempt to\r\nregain access to the environment\r\nIndicators of Compromise (IOCs)\r\nIndicator Details\r\nhttp://satkas.waw\u003c.\u003epl/rainloop/forecast TrailBlazer C2\r\n1326932d63485e299ba8e03bfcd23057f7897c3ae0d26ed1235c4fb108adb105 TrailBlazer SHA256\r\nvm-srv-1.gel.ulaval.ca GoldMax C2\r\n2a3b660e19b56dad92ba45dd164d300e9bd9c3b17736004878f45ee23a0177ac GoldMax SHA256\r\n156.96.46.116 TA Infrastructure\r\n188.34.185.85 TA Infrastructure\r\n212.103.61.74 TA Infrastructure\r\n192.154.224.126 TA Infrastructure\r\n23.29.115.180 TA Infrastructure\r\n104.237.218.74 TA Infrastructure\r\n23.82.128.144 TA Infrastructure\r\nAdditional Resources\r\nRead about the latest trends in threat hunting and more in the 2021 Threat Hunting Report or simply\r\ndownload the report now.\r\nLearn more about Falcon OverWatch proactive managed threat hunting.\r\nWatch this video to see how Falcon OverWatch proactively hunts for threats in your environment.\r\nLearn more about the CrowdStrike Falcon® platform by visiting the product webpage.\r\nTest CrowdStrike next-gen AV for yourself. Start your free trial of Falcon Prevent™ today.\r\nSource: https://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/\r\nhttps://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/\r\nPage 19 of 19", "extraction_quality": 1, "language": "EN", "sources": [ "ETDA", "Malpedia", "MITRE" ], "origins": [ "web" ], "references": [ "https://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/" ], "report_names": [ "observations-from-the-stellarparticle-campaign" ], "threat_actors": [ { "id": "b43e5ea9-d8c8-4efa-b5bf-f1efb37174ba", "created_at": "2022-10-25T16:07:24.36191Z", "updated_at": "2026-04-10T02:00:04.954902Z", "deleted_at": null, "main_name": "UNC2452", "aliases": [ "Dark Halo", "Nobelium", "SolarStorm", "StellarParticle", "UNC2452" ], "source_name": "ETDA:UNC2452", "tools": [], "source_id": "ETDA", "reports": null }, { "id": "1d3f9dec-b033-48a5-8b1e-f67a29429e89", "created_at": "2022-10-25T15:50:23.739197Z", "updated_at": "2026-04-10T02:00:05.275809Z", "deleted_at": null, "main_name": "UNC2452", "aliases": [ "UNC2452", "NOBELIUM", "StellarParticle", "Dark Halo" ], "source_name": "MITRE:UNC2452", "tools": [ "Sibot", "Mimikatz", "Cobalt Strike", "AdFind", "GoldMax" ], "source_id": "MITRE", "reports": null }, { "id": "5b748f86-ac32-4715-be9f-6cf25ae48a4e", "created_at": "2024-06-04T02:03:07.956135Z", "updated_at": "2026-04-10T02:00:03.689959Z", "deleted_at": null, "main_name": "IRON HEMLOCK", "aliases": [ "APT29 ", "ATK7 ", "Blue Kitsune ", "Cozy Bear ", "The Dukes", "UNC2452 ", "YTTRIUM " ], "source_name": "Secureworks:IRON HEMLOCK", "tools": [ "CosmicDuke", "CozyCar", "CozyDuke", "DiefenDuke", "FatDuke", "HAMMERTOSS", "LiteDuke", "MiniDuke", "OnionDuke", "PolyglotDuke", "RegDuke", "RegDuke Loader", "SeaDuke", "Sliver" ], "source_id": "Secureworks", "reports": null }, { "id": "a241a1ca-2bc9-450b-a07b-aae747ee2710", "created_at": "2024-06-19T02:03:08.150052Z", "updated_at": "2026-04-10T02:00:03.737173Z", "deleted_at": null, "main_name": "IRON RITUAL", "aliases": [ "APT29", "Blue Dev 5 ", "BlueBravo ", "Cloaked Ursa ", "CozyLarch ", "Dark Halo ", "Midnight Blizzard ", "NOBELIUM ", "StellarParticle ", "UNC2452 " ], "source_name": "Secureworks:IRON RITUAL", "tools": [ "Brute Ratel C4", "Cobalt Strike", "EnvyScout", "GoldFinder", "GoldMax", "NativeZone", "RAINDROP", "SUNBURST", "Sibot", "TEARDROP", "VaporRage" ], "source_id": "Secureworks", "reports": null }, { "id": "46b3c0fc-fa0c-4d63-a38a-b33a524561fb", "created_at": "2023-01-06T13:46:38.393409Z", "updated_at": "2026-04-10T02:00:02.955738Z", "deleted_at": null, "main_name": "APT29", "aliases": [ "Cloaked Ursa", "TA421", "Blue Kitsune", "BlueBravo", "IRON HEMLOCK", "G0016", "Nobelium", "Group 100", "YTTRIUM", "Grizzly Steppe", "ATK7", "ITG11", "COZY BEAR", "The Dukes", "Minidionis", "UAC-0029", "SeaDuke" ], "source_name": "MISPGALAXY:APT29", "tools": [ "SNOWYAMBER", "HALFRIG", "QUARTERRIG" ], "source_id": "MISPGALAXY", "reports": null }, { "id": "70872c3a-e788-4b55-a7d6-b2df52001ad0", "created_at": "2023-01-06T13:46:39.18401Z", "updated_at": "2026-04-10T02:00:03.239111Z", "deleted_at": null, "main_name": "UNC2452", "aliases": [ "DarkHalo", "StellarParticle", "NOBELIUM", "Solar Phoenix", "Midnight Blizzard" ], "source_name": "MISPGALAXY:UNC2452", "tools": [ "SNOWYAMBER", "HALFRIG", "QUARTERRIG" ], "source_id": "MISPGALAXY", "reports": null }, { "id": "20d3a08a-3b97-4b2f-90b8-92a89089a57a", "created_at": "2022-10-25T15:50:23.548494Z", "updated_at": "2026-04-10T02:00:05.292748Z", "deleted_at": null, "main_name": "APT29", "aliases": [ "APT29", "IRON RITUAL", "IRON HEMLOCK", "NobleBaron", "Dark Halo", "NOBELIUM", "UNC2452", "YTTRIUM", "The Dukes", "Cozy Bear", "CozyDuke", "SolarStorm", "Blue Kitsune", "UNC3524", "Midnight Blizzard" ], "source_name": "MITRE:APT29", "tools": [ "PinchDuke", "ROADTools", "WellMail", "CozyCar", "Mimikatz", "Tasklist", "OnionDuke", "FatDuke", "POSHSPY", "EnvyScout", "SoreFang", "GeminiDuke", "reGeorg", "GoldMax", "FoggyWeb", "SDelete", "PolyglotDuke", "AADInternals", "MiniDuke", "SeaDuke", "Sibot", "RegDuke", "CloudDuke", "GoldFinder", "AdFind", "PsExec", "NativeZone", "Systeminfo", "ipconfig", "Impacket", "Cobalt Strike", "PowerDuke", "QUIETEXIT", "HAMMERTOSS", "BoomBox", "CosmicDuke", "WellMess", "VaporRage", "LiteDuke" ], "source_id": "MITRE", "reports": null }, { "id": "f27790ff-4ee0-40a5-9c84-2b523a9d3270", "created_at": "2022-10-25T16:07:23.341684Z", "updated_at": "2026-04-10T02:00:04.549917Z", "deleted_at": null, "main_name": "APT 29", "aliases": [ "APT 29", "ATK 7", "Blue Dev 5", "BlueBravo", "Cloaked Ursa", "CloudLook", "Cozy Bear", "Dark Halo", "Earth Koshchei", "G0016", "Grizzly Steppe", "Group 100", "ITG11", "Iron Hemlock", "Iron Ritual", "Midnight Blizzard", "Minidionis", "Nobelium", "NobleBaron", "Operation Ghost", "Operation Office monkeys", "Operation StellarParticle", "SilverFish", "Solar Phoenix", "SolarStorm", "StellarParticle", "TEMP.Monkeys", "The Dukes", "UNC2452", "UNC3524", "Yttrium" ], "source_name": "ETDA:APT 29", "tools": [ "7-Zip", "ATI-Agent", "AdFind", "Agentemis", "AtNow", "BEATDROP", "BotgenStudios", "CEELOADER", "Cloud Duke", "CloudDuke", "CloudLook", "Cobalt Strike", "CobaltStrike", "CosmicDuke", "Cozer", "CozyBear", "CozyCar", "CozyDuke", "Danfuan", "EnvyScout", "EuroAPT", "FatDuke", "FoggyWeb", "GeminiDuke", "Geppei", "GoldFinder", "GoldMax", "GraphDrop", "GraphicalNeutrino", "GraphicalProton", "HAMMERTOSS", "HammerDuke", "LOLBAS", "LOLBins", "LiteDuke", "Living off the Land", "MagicWeb", "Mimikatz", "MiniDionis", "MiniDuke", "NemesisGemina", "NetDuke", "OnionDuke", "POSHSPY", "PinchDuke", "PolyglotDuke", "PowerDuke", "QUIETEXIT", "ROOTSAW", "RegDuke", "Rubeus", "SNOWYAMBER", "SPICYBEAT", "SUNSHUTTLE", "SeaDaddy", "SeaDask", "SeaDesk", "SeaDuke", "Sharp-SMBExec", "SharpView", "Sibot", "Solorigate", "SoreFang", "TinyBaron", "WINELOADER", "WellMail", "WellMess", "cobeacon", "elf.wellmess", "reGeorg", "tDiscoverer" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434414, "ts_updated_at": 1775826782, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/4a216180518b7ec5c50c65563b5ddf06097093e8.pdf", "text": "https://archive.orkl.eu/4a216180518b7ec5c50c65563b5ddf06097093e8.txt", "img": "https://archive.orkl.eu/4a216180518b7ec5c50c65563b5ddf06097093e8.jpg" } }