{ "id": "3625ae00-3f4b-4e4b-b748-f6695beaadd5", "created_at": "2026-04-06T00:12:21.733605Z", "updated_at": "2026-04-10T03:37:33.285431Z", "deleted_at": null, "sha1_hash": "0cb3ea6f074bb99db8727913700a58932ac664be", "title": "GoldMax, GoldFinder, and Sibot: Analyzing NOBELIUM’s layered persistence | Microsoft Security Blog", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 704375, "plain_text": "GoldMax, GoldFinder, and Sibot: Analyzing NOBELIUM’s layered\r\npersistence | Microsoft Security Blog\r\nBy Ramin Nafisi, Andrea Lelli, Microsoft Threat Intelligence\r\nPublished: 2021-03-04 · Archived: 2026-04-05 14:16:47 UTC\r\nApril 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the\r\ntheme of weather. NOBELIUM is now tracked as Midnight Blizzard. \r\nApril 15, 2021 update – We updated this blog with new indicators of compromise, including files, domains, and C2 decoy\r\ntraffic, released by Cybersecurity \u0026 Infrastructure Security Agency (CISA) in Malware Analysis Report MAR-10327841-\r\n1.v1 – SUNSHUTTLE.  \r\nMicrosoft continues to work with partners and customers to expand our knowledge of the threat actor behind the nation-state\r\ncyberattacks that compromised the supply chain of SolarWinds and impacted multiple other organizations. As we have\r\nshared previously, we have observed the threat actor using both backdoor and other malware implants to establish sustained\r\naccess to affected networks. As part of our commitment to transparency and intelligence-sharing in the defender community,\r\nwe continue to update analysis and investigative resources as we discover new tactics and techniques used by the threat\r\nactor.\r\nIntroducing NOBELIUM\r\nMicrosoft Threat Intelligence Center (MSTIC) is naming the actor behind the attacks against SolarWinds, the SUNBURST\r\nbackdoor, TEARDROP malware, and related components as NOBELIUM.\r\nRecent investigations have identified three new pieces of malware being used in late-stage activity by NOBELIUM. This\r\nblog provides detailed analysis of these malware strains to help defenders detect, protect, and respond to this threat. We\r\ncontinue to partner with FireEye to understand these threats and protect our mutual customers. FireEye’s analysis of the\r\nmalware used by NOBELIUM is here.\r\nMicrosoft discovered these new attacker tools and capabilities in some compromised customer networks and observed them\r\nto be in use from August to September 2020. Further analysis has revealed these may have been on compromised systems as\r\nearly as June 2020. These tools are new pieces of malware that are unique to this actor. They are tailor-made for specific\r\nnetworks and are assessed to be introduced after the actor has gained access through compromised credentials or the\r\nSolarWinds binary and after moving laterally with TEARDROP and other hands-on-keyboard actions.\r\nThese capabilities differ from previously known NOBELIUM tools and attack patterns, and reiterate the actor’s\r\nsophistication. In all stages of the attack, the actor demonstrated a deep knowledge of software tools, deployments, security\r\nsoftware and systems common in networks, and techniques frequently used by incident response teams. This knowledge is\r\nreflected in the actor’s operational decisions, from the choice of command-and-control (C2) infrastructure to the naming of\r\nscheduled tasks used to maintain persistence.\r\nWith this actor’s established pattern of using unique infrastructure and tooling for each target, and the operational value of\r\nmaintaining their persistence on compromised networks, it is likely that additional components will be discovered as our\r\ninvestigation into the actions of this threat actor continues.\r\nNew NOBELIUM malware\r\nMaintaining persistence is critical for any threat actor after gaining access to a network. In addition to the backdoor in the\r\nSolarWinds software, NOBELIUM has been observed using stolen credentials to access cloud services like email and\r\nstorage, as well as compromised identities to gain and maintain access to networks via virtual private networks (VPNs) and\r\nremote access tools. Microsoft assesses that the newly surfaced pieces of malware were used by the actor to maintain\r\npersistence and perform actions on very specific and targeted networks post-compromise, even evading initial detection\r\nduring incident response.\r\nhttps://www.microsoft.com/security/blog/2021/03/04/goldmax-goldfinder-sibot-analyzing-nobelium-malware\r\nPage 1 of 16\n\nGoldMax\r\nThe GoldMax malware was discovered persisting on networks as a scheduled task impersonating systems management\r\nsoftware. In the instances it was encountered, the scheduled task was named after software that existed in the environment,\r\nand pointed to a subfolder in ProgramData named after that software, with a similar executable name. The executable,\r\nhowever, was the GoldMax implant.\r\nWritten in Go, GoldMax acts as command-and-control backdoor for the actor. It uses several different techniques to\r\nobfuscate its actions and evade detection. The malware writes an encrypted configuration file to disk, where the file name\r\nand AES-256 cipher keys are unique per implant and based on environmental variables and information about the network\r\nwhere it is running.\r\nGoldMax establishes a secure session key with its C2 and uses that key to securely communicate with the C2, preventing\r\nnon-GoldMax-initiated connections from receiving and identifying malicious traffic. The C2 can send commands to be\r\nlaunched for various operations, including native OS commands, via psuedo-randomly generated cookies. The hardcoded\r\ncookies are unique to each implant, appearing to be random strings but mapping to victims and operations on the actor side.\r\nObserved GoldMax C2 domains are high-reputation and high-prevalence, often acquired from domain resellers so that\r\nWhois records retain the creation date from their previous registration, or domains that may have been compromised. This\r\ntactic complements NOBELIUM’s operational security strategy as these domains are more likely to be overlooked by\r\nsecurity products and analysts based on their perceived long-lived domain ownership. Put simply, several domains we have\r\nshared as GoldMax C2 domains are only associated with NOBELIUM after the time they were re-sold or compromised –\r\nand Microsoft has provided that indicator context where it is available to us.\r\nUpon execution, GoldMax retrieves a list of the system’s network interfaces; the malware terminates if it is unable to do so\r\nor no network interface is configured. It then attempts to determine if any of the network interfaces has the following\r\nhardcoded MAC address: c8:27:cc:c2:37:5a. If so, it terminates.\r\nFigure 1. HardwareAddr.String() call, hardcoded MAC address, and os.Exit() call\r\nConfiguration file\r\nGoldMax is designed to store its configuration data in an encrypted file named features.dat.tmp. The file name varies in\r\ndifferent versions of GoldMax, but in all observed variants, the configuration file carries a .tmp file extension and is located\r\nin the same directory as GoldMax. The first time GoldMax is run, it uses a set of embedded default values to create and\r\npopulate its configuration file on disk. The next time GoldMax  runs, instead of using its embedded configuration data, it\r\nloads the configuration data from its configuration file stored on the file system.\r\nThe data from the configuration file typically matches the default configuration data embedded in GoldMax, since the\r\nembedded data was initially used to create the configuration file. However, GoldMax comes with a command-and-control\r\nfeature that allows its operators to dynamically update its configuration data on the fly. When this happens, GoldMax\r\nhttps://www.microsoft.com/security/blog/2021/03/04/goldmax-goldfinder-sibot-analyzing-nobelium-malware\r\nPage 2 of 16\n\noverwrites the existing data in its configuration file with the new configuration data received from its operators, so the next\r\ntime GoldMax is run, it uses the most up-to-date version of its configuration data to initialize its runtime settings.\r\nThe configuration data is encrypted using the AES-256 encryption algorithm, CFB encryption mode, and the following\r\ncipher key: 4naehrkz5alao2jd035zjh3j1v1dvyyc (key varies in different versions of GoldMax). The AES encrypted\r\nconfiguration data is then Base64-encoded using the custom Base64 alphabet\r\n“ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_” before it is stored in the\r\nconfiguration file on the file system. When run, GoldMax decodes (Base64) and decrypts (AES-256) the configuration data\r\nto reveal a custom data structure comprised of the following dynamically generated and hardcoded values (delimited by ‘|’):\r\nFigure 2. Data structure of the GoldMax configuration data\r\nGoldMax proceeds to parse the data structure depicted above and uses the values within to initialize its runtime settings and\r\nvariables used by its different components.\r\nIf the configuration file is not present on the system, (i.e., the first time it runs), GoldMax uses dynamically generated and\r\nembedded values to create and populate the data structure depicted above. It then uses the same AES encryption\r\nmethodology to encrypt the data structure. After encrypting the data structure, GoldMax proceeds to Base64 encode the\r\nencrypted data structure and removes all instances of ‘=’ from the Base64 encoded string. It then creates a configuration file\r\non the file system (e.g., features.dat.tmp) and stores the Base64 encoded data in the configuration file.\r\nActivation date\r\nGoldMax’s configuration data contains an execution activation/trigger date, stored as an ASCII Unix/Epoch time value as\r\nshown in the configuration data section above, that is essentially meant to function as an “activate after x date/time” feature.\r\nAfter loading its configuration data, GoldMax checks the current date-time value of the compromised system against the\r\nactivation date from the configuration data.\r\nhttps://www.microsoft.com/security/blog/2021/03/04/goldmax-goldfinder-sibot-analyzing-nobelium-malware\r\nPage 3 of 16\n\nFigure 3. Inline Unix() function and EPOCH comparison of the current and activation date/time\r\nIf an activation date-time value is specified in the configuration data (i.e., not set to ‘0’) and the activation date-time occurs\r\non or before the current date-time of the compromised system, GoldMax commences its malicious activities. Otherwise,\r\nGoldMax terminates and continues to do so until the activation date is reached. If no activation date is specified in the\r\nconfiguration data (i.e., field set to ‘0’), the malware commences its malicious activities straightaway.\r\nIn all versions of GoldMax analyzed during our investigation, the activation date is initially set to ‘0’. However, through its\r\ncommand-and-control feature, the operators can dynamically update the activation date using a specific C2 command, in\r\nwhich case the new activation date is stored in the configuration file and is checked each time GoldMax runs.\r\nDecoy network traffic\r\nGoldMax is equipped with a decoy network traffic generation feature that allows it to surround its malicious network traffic\r\nwith seemingly benign traffic. This feature is meant to make distinguishing between malicious and benign traffic more\r\nchallenging. If the decoy network traffic feature is enabled (set to ‘1’ in the configuration data), GoldMax issues a pseudo-random number of decoy HTTP GET requests (up to four) for URLs pointing to a mixture of legitimate and C2 domain\r\nnames and/or IP addresses. The exact URL for each request is pseudo-randomly selected from a list of 14 hardcoded URLs.\r\nAn example URL list comprised of 14 legitimate and C2 URLs is shown below:\r\nFigure 4. Hardcoded URLs from which GoldMax selects up to four to issue HTTP requests for\r\nhttps://www.microsoft.com/security/blog/2021/03/04/goldmax-goldfinder-sibot-analyzing-nobelium-malware\r\nPage 4 of 16\n\nAs shown above, some of the decoy URLs point to the domain name of the actual C2 (e.g., onetechcompany[.]com).\r\nHowever, the particular HTTP resources referenced in the URLs above (e.g., style.css, script.js, icon.ico, etc.) are known to\r\nthe C2 as being decoy resources that serve no role in the regular C2 communication between GoldMax and its C2.\r\nThe Referer value for each decoy HTTP request is also pseudo-randomly selected from a list of four legitimate domain\r\nnames. For example, we have seen the following in various combinations to make up lists of four\r\ndomains: www[.]mail[.]com, www[.]bing[.]com, www[.]facebook[.]com, www[.]google[.]com, www[.]twitter[.]com, www[.]yahoo[.]com,\r\netc. For demonstration purposes, an example decoy HTTP GET request is included below (the Connection and User-Agent\r\nHTTP headers and their values are manually added to each request by GoldMax and remain the same across all decoy HTTP\r\nrequests, regardless of the destination URL):\r\nFigure 5. Sample decoy HTTP GET request\r\nRSA session key\r\nThe next step in the execution cycle involves establishing a secure session key between GoldMax and its C2 server.\r\nGoldMax first requests a session key from its C2 server by sending an HTTP GET request that contains a custom HTTP\r\nCookie value that is unique to each implant. The Cookie value is comprised of the following dynamically generated and\r\nhardcoded values:\r\nFigure 6. HTTP Cookie value in HTTP GET request\r\nAn example request containing the custom Cookie value is shown below:\r\nFigure 7. Sample HTTP GET request with the custom Cookie value\r\nThe User-Agent and Connection values above are hardcoded in the HTTP request. The Referer value is pseudo-randomly\r\nselected from a list of four legitimate domain names using various combinations of the\r\nfollowing: www[.]mail[.]com, www[.]bing[.]com, www[.]facebook[.]com, www[.]google[.]com, www[.]twitter[.]com, www[.]yahoo[.]com,\r\netc.\r\nIn response to the request above, GoldMax expects to receive an HTTP 200 response containing a very specific and\r\nhardcoded ASCII string (e.g., “uFLa12nFmKkjrmjj”). The seemingly random-looking string is typically 10-16 bytes long\r\n(after all leading and trailing white space has been removed). It can best be described as a “shared secret” between the C2\r\nand each individual implant (the string varies in different versions of GoldMax). It serves as an acknowledgement that the\r\nC2 server has received GoldMax’s request for a new a session key. If GoldMax does not receive the expected string, it\r\nsleeps for a random amount of time and repeats (indefinitely) the process described above to obtain the expected string from\r\nits C2 server, or until the GoldMax process is terminated.\r\nhttps://www.microsoft.com/security/blog/2021/03/04/goldmax-goldfinder-sibot-analyzing-nobelium-malware\r\nPage 5 of 16\n\nAfter receiving the expected string, GoldMax sleeps for up to 14 seconds before proceeding. If the decoy traffic option is\r\nenabled in the configuration data, GoldMax issues a pseudo-random number of HTTP GET requests (as described under the\r\ndecoy network traffic section above). GoldMax then issues a new HTTP GET request to its C2 server containing a new set\r\nof hardcoded Cookie values.\r\nFigure 8. Sample HTTP GET request showing hardcoded Cookie values\r\nThe only observed difference between the first and second HTTP GET requests is the value of the second Cookie\r\nhighlighted above (example values: iC0Pf2a48 from the first request vs. J4yeUYKyeuNa2 from the second request above).\r\nIn response to the request, GoldMax receives an encrypted RSA session key (Base64-encoded). Each version of GoldMax\r\ncontains an RSA private key which GoldMax proceeds to decode (using pem.Decode()) and parse\r\n(using x509.ParsePKCS1PrivateKey()). GoldMax uses rsa.DecryptOAEP() with the parsed private key to decrypt (using\r\nRSA-OAEP) the RSA-encrypted session key received from its C2 server. From this point on, the session key is used to\r\nencrypt data sent between GoldMax and its C2 server.\r\nC2 commands\r\nAfter establishing a session key, GoldMax reaches out to its C2 server to receive, decrypt (AES-256), parse, and execute\r\ncommands. To retrieve an encrypted C2 command from its C2 server, GoldMax sends an HTTP GET request. This HTTP\r\nGET request only contains a single Cookie value, which matches the Cookie value used during the session key\r\nestablishment process (the User-Agent and Connection headers and values are hardcoded, as before):\r\nFigure 9. Sample HTTP GET request containing a single Cookie value\r\nIn response to the request above, GoldMax receives an encrypted (AES-256) and encoded (Base64 using custom Base64\r\nalphabet) C2 command. The command is encrypted using the session key established between GoldMax and its C2 server.\r\nAfter decoding and decrypting the C2 command, GoldMax proceeds to parse the C2 command.\r\nC2 commands are represented as seemingly random alphanumerical ASCII strings (e.g., “KbwUQrcooAntqNMddu4XRj”)\r\nthat are unique to each implant but known to the C2 server. The C2 commands allow the operator to download and execute\r\nfiles on the compromised system, upload files from the compromised system to the C2 server, execute OS commands on the\r\ncompromised system, spawn a command shell, and dynamically update GoldMax’s configuration data. These dynamic\r\nupdates to Goldmax configuration data enable ability to set a new activation date, replace the existing C2 URL and User-Agent values, enable/disable decoy network traffic feature, and update the number range used by its PRNG.\r\nIt is worth noting that all observed versions of GoldMax were compiled with the Go compiler version 1.14.2 (released in\r\nApril 2020). In all observed versions, the main Go source code file for GoldMax was located under the following\r\ndirectory: /var/www/html/builds/. The Go packages and libraries used during the compilation process of GoldMax were\r\nmostly located under the /var/www/html/go/src/ directory (e.g., /var/www/html/go/src/net/http/http.go).\r\nSibot\r\nhttps://www.microsoft.com/security/blog/2021/03/04/goldmax-goldfinder-sibot-analyzing-nobelium-malware\r\nPage 6 of 16\n\nSibot is a dual-purpose malware implemented in VBScript. It is designed to achieve persistence on the infected machine\r\nthen download and execute a payload from a remote C2 server.  The VBScript file is given a name that impersonates\r\nlegitimate Windows tasks and is either stored in the registry of the compromised system or in an obfuscated format on disk.\r\nThe VBScript is then run via a scheduled task.\r\nSibot reaches out to a legitimate but compromised website to download a DLL to a folder under System32. In observed\r\ninstances the DLL is downloaded to C:\\windows\\system32\\drivers\\, renamed with a .sys extension, and then executed\r\nby rundll32. The scheduled task calls an MSHTA application to run Sibot via the obfuscated script. This simplistic\r\nimplementation allows for a low footprint for the actor, as they can download and run new code without changes to the\r\ncompromised endpoint by just updating the hosted DLL. The compromised website used to host the DLL is different for\r\nevery compromised network and includes websites of medical device manufacturers and IT service providers.\r\nWe have observed three variants of this malware, all of which are obfuscated:\r\nVariant A is the simplest of the three. It only installs the second-stage script in the default registry value under the\r\nregistry key HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\sibot.\r\n Variant B registers a scheduled task named Sibot and programmed to run daily. This task, which is saved by\r\nWindows in the file C:\\Windows\\System32\\Tasks\\Microsoft\\Windows\\WindowsUpdate\\sibot, runs the following\r\ncommand-line daily:\r\nThe registry key referenced in this command-line contains the second-stage script.\r\nVariant C is a standalone version of the second-stage script. However, while the second-stage script from Variant A\r\nis designed to be executed from the registry, this variant is designed to run from a file.\r\nFigure 10. Sibot variants\r\nThe second-stage script\r\nThe purpose of the second-stage script is to download and run a payload from a remote server. The script can be customized\r\nwith the following parameters:\r\nhttps://www.microsoft.com/security/blog/2021/03/04/goldmax-goldfinder-sibot-analyzing-nobelium-malware\r\nPage 7 of 16\n\nCommand-line with which to run the payload\r\nDirectory where the payload is installed\r\nURL of the C2 server containing the payload to download\r\nHTTP request to use for the download (e.g., GET)\r\nWhen run, the first thing the script does is to retrieve a GUID associated to a LAN connection present on the machine by\r\nleveraging the interface offered by the WMI Class Root\\Microsoft\\Homenet\\HNet_Connection. If a LAN connection is not\r\navailable, the script defaults to a hardcoded GUID. This GUID is later communicated to the C2. It’s possible that the threat\r\nactor used this GUID to verify that the threat is running in a desirable environment, i.e., a real machine with LAN\r\nconnections available. The next step of the second-stage script is to check if the machine is configured to use proxies, and if\r\nso, to get the address of a proxy. The script uses the StdRegProv WMI class to read the configuration data from the registry\r\nkey  HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\ProxyServer and extract a\r\nvalid proxy server.\r\nAt this point, the script establishes an HTTP connection to the C2 server. It sets the user-agent and the connection GUID as\r\nHTTP header variables, then sends the HTTP request. In both versions of the script, the request is GET. If the server\r\nresponse is comprised only of the same GUID that the malware sent, the script deletes itself. In the case of the second-stage\r\nscript from Variant A, the script deletes the registry key where it is installed. In the case of Variant C, the script deletes the\r\nfile from which it is running. If instead the server responds with any data other than the GUID, the second-stage script\r\ndecrypts the data and saves it as a file. In both variants of the second-stage script, the payload is a DLL with a .SYS\r\nextension and saved in the %windir%\\system32\\drivers folder. Finally, the script uses the Win32_Process WMI class to\r\nexecute the payload DLL via the rundll32.exe utility.\r\nWhile the script is running in the context of a script host process (e.g. wscript.exe), the actions carried out through the WMI\r\ninterface originates from the WMI host process (WmiPrvSe.exe). This effectively breaks the process chain between the\r\naction’s origin (the script host) and its execution (the WMI host), making it more difficult to trace back events to their true\r\norigin. Forensic analysis is also hindered by the lack of correlation between the execution of the second-stage script and the\r\nevents it carries out via WMI.\r\nThe following Python script can be used to decode encoded strings observed in Sibot samples analyzed in this report.\r\nPython\r\nencoded = '\u003cencoded string'=\"\" decoded=\"\" i=\"0\" while=\"\" \u003c=\"\" len(encoded):=\"\" a=\"int(chr(ord(encoded[i])\" -\r\n=\"\" 17))=\"\" +=\"1\" b=\"int(chr(ord(encoded[i])\" if=\"\" *=\"\" 10=\"\" 32:=\"\" c=\"int(chr(ord(encoded[i])\" 100=\"\" c)=\"\"\r\nelse:=\"\" b)=\"\" print(decoded)=\"\" pre=\"\"\u003e\u003c/encoded\u003e\r\nGoldFinder\r\nAnother tool written in Go, GoldFinder was most likely used as a custom HTTP tracer tool that logs the route or hops that a\r\npacket takes to reach a hardcoded C2 server. When launched, the malware issues an HTTP request for a hardcoded IP\r\naddress (e.g., hxxps://185[.]225[.]69[.]69/) and logs the HTTP response to a plaintext log file (e.g., loglog.txt created in the\r\npresent working directory). GoldFinder uses the following hardcoded labels to store the request and response information in\r\nthe log file:\r\nTarget: The C2 URL\r\nStatusCode: HTTP response/status code\r\nHeaders: HTTP response headers and their values\r\nData: Data from the HTTP response received from the C2\r\nAn example log entry using a sample date is shown below:\r\nFigure 11. Sample log entry\r\nhttps://www.microsoft.com/security/blog/2021/03/04/goldmax-goldfinder-sibot-analyzing-nobelium-malware\r\nPage 8 of 16\n\nIf the response is not an HTTP 200 (OK) response and contains an HTTP Location field (indicating a redirect), GoldFinder\r\nrecursively follows and logs the redirects until it receives an HTTP 200 response, at which point it terminates. If a Location\r\nheader is present in the response and the Location value starts with the string “http”, GoldFinder extracts the Location URL\r\n(i.e., redirect URL) and issues a new HTTP GET request for the redirect URL. It again logs the request and its response in\r\nthe plaintext log file:\r\nFigure 12. Sample log file\r\nIf GoldFinder receives an HTTP 200 status code in response to the request above, indicating no more redirects, it terminates.\r\nOtherwise, it recursively follows the redirect up to 99 times or until it receives an HTTP 200 response, whichever occurs\r\nfirst.\r\nWhen launched, GoldFinder can identify all HTTP proxy servers and other redirectors such as network security devices that\r\nan HTTP request travels through inside and outside the network to reach the intended C2 server. When used on a\r\ncompromised device, GoldFinder can be used to inform the actor of potential points of discovery or logging of their other\r\nactions, such as C2 communication with GoldMax.\r\nGoldFinder was compiled using Go 1.14.2, released in April 2020, from a Go file named finder.go with the following\r\npath: /tmp/finder.go. The Go packages and libraries used during the compilation process of GoldFinder were mostly located\r\nunder the /var/www/html/go/src/ directory (e.g., /var/www/html/go/src/net/http/http.go).\r\nComprehensive protections for persistent techniques\r\nThe sophisticated NOBELIUM attack requires a comprehensive incident response to identify, investigate, and respond. Get\r\nthe latest information and guidance from Microsoft at https://aka.ms/nobelium.\r\nMicrosoft Defender Antivirus detects the new NOBELIUM components discussed in this blog as the following malware:\r\nTrojan:Win64/GoldMax.A!dha\r\nTrojanDownloader:VBS/Sibot.A!dha\r\nTrojan:VBS/Sibot.B!dha\r\nTrojan:Win64/GoldFinder.A!dha\r\nBehavior:Win32/Sibot.C\r\nTurning on cloud-delivered protection and automatic sample submission on Microsoft Defender Antivirus ensures that\r\nartificial intelligence and machine learning can quickly identify and stop new and unknown threats. Tamper protection\r\nfeatures prevent attackers from stopping security services. Attack surface reduction rules, specifically the rule Block\r\nexecutable files from running unless they meet a prevalence, age, or trusted list criterion, can help block new malware and\r\nattacker tools introduced by threat actors.\r\nhttps://www.microsoft.com/security/blog/2021/03/04/goldmax-goldfinder-sibot-analyzing-nobelium-malware\r\nPage 9 of 16\n\nFigure 13. Security recommendations in threat and vulnerability management\r\nDetections of new malware by Microsoft Defender Antivirus are reported as alerts in Microsoft Defender Security Center.\r\nAdditionally, endpoint detection and response capabilities in Microsoft Defender for Endpoint detect malicious behavior\r\nrelated to these NOBELIUM components, which are surfaced as alerts with the following titles:\r\nGoldMax malware\r\nSibot malware\r\nGoldFinder Malware\r\nThe following alerts, which indicate detection of behavior associated with a wide range of attacks, are also raised for these\r\nNOBELIUM components:\r\nSuspicious connection to remote service\r\nSuspicious Rundll32 Process Execution\r\nSuspicious PowerShell command line\r\nSuspicious file or script accessed a malicious registry key\r\nIntelligence about these newly surfaced components accrue to the information about NOBELIUM that Microsoft 365\r\nDefender consolidates. Rich investigation tools in Microsoft 365 Defender allow security operations teams to\r\ncomprehensively respond to this attack. Get comprehensive guidance for using Microsoft 365 Defender to identify,\r\ninvestigate, and respond to the NOBELIUM attack.\r\nIndicators of compromise (IOCs)\r\nDue to the nature of this attack, most samples are unique to each network they were discovered in, however Microsoft has\r\nconfirmed that these samples available in public repositories are associated with this threat.\r\nType\r\nThreat\r\nname\r\nIndicator\r\nSHA-256\r\nGoldMax 70d93035b0693b0e4ef65eb7f8529e6385d698759cc5b8666a394b2136cc06eb\r\nSHA-256\r\nGoldMax 0e1f9d4d0884c68ec25dec355140ea1bab434f5ea0f86f2aade34178ff3a7d91\r\nSHA-256\r\nGoldMax 247a733048b6d5361162957f53910ad6653cdef128eb5c87c46f14e7e3e46983\r\nSHA-256\r\nGoldMax f28491b367375f01fb9337ffc137225f4f232df4e074775dd2cc7e667394651c\r\nSHA-256\r\nGoldMax 611458206837560511cb007ab5eeb57047025c2edc0643184561a6bf451e8c2c\r\nhttps://www.microsoft.com/security/blog/2021/03/04/goldmax-goldfinder-sibot-analyzing-nobelium-malware\r\nPage 10 of 16\n\nSHA-256\r\nGoldMax b9a2c986b6ad1eb4cfb0303baede906936fe96396f3cf490b0984a4798d741d8\r\nSHA-256\r\nGoldMax bbd16685917b9b35c7480d5711193c1cd0e4e7ccb0f2bf1fd584c0aebca5ae4c\r\nSHA-256\r\nGoldFinder 0affab34d950321e3031864ec2b6c00e4edafb54f4b327717cb5b042c38a33c9\r\nSHA-256\r\nSibot 7e05ff08e32a64da75ec48b5e738181afb3e24a9f1da7f5514c5a11bb067cbfb\r\nSHA-256\r\nSibot acc74c920d19ea0a5e6007f929ef30b079eb2836b5b28e5ffcc20e68fa707e66\r\nIP\r\naddress\r\nGoldMax\r\nand\r\nGoldFinder\r\n185[.]225[.]69[.]69/\r\nDomain\r\nGoldMax\r\nand\r\nGoldFinder\r\nsrfnetwork[.]org\r\nDomain GoldMax reyweb[.]com\r\nDomain GoldMax onetechcompany [.]com\r\nAdditional IOCs added April 15, 2021:\r\nType\r\nThreat\r\nname\r\nIndicator\r\nSHA-256\r\nGoldMax 4e8f24fb50a08c12636f3d50c94772f355d5229e58110cccb3b4835cb2371aec\r\nSHA-256\r\nGoldMax ec5f07c169267dec875fdd135c1d97186b494a6f1214fb6b40036fd4ce725def\r\nSHA-256\r\nGoldMax 478b04c20bbf6717d10ee978b99339b7c4664febc8bcfdaf86c3f0fbfc83a5c5\r\nSHA-256\r\nGoldFinder f2a8bdf135caca0d7359a7163a4343701a5bdfbc8007e71424649e45901ab7e2\r\nSHA-256\r\nGoldFinder 4dec3eeefcec013f142386d5c54099d3daa2b48d559434db1d4f2078d704da1b\r\nSHA-256\r\nGoldFinder 6b01eeef147d9e0cd6445f90e55e467b930df2de5d74e3d2f7610e80f2c5a2cd\r\nSHA-256\r\nGoldFinder 0f04f199327d0d076815190dc024f4a6b0f27899d50d28e94662820ab9c945d2\r\nSHA-256\r\nSibot e9ddf486e5aeac02fc279659b72a1bec97103f413e089d8fabc30175f4cdbf15\r\nSHA-256\r\nSibot cb80a074e5fde8d297c2c74a0377e612b4030cc756baf4fff3cc2452ebc04a9c\r\nDomain GoldMax megatoolkit[.]com\r\nDomain GoldMax\r\nand\r\nNikeoutletinc[.]org\r\nhttps://www.microsoft.com/security/blog/2021/03/04/goldmax-goldfinder-sibot-analyzing-nobelium-malware\r\nPage 11 of 16\n\nGoldFinder\r\nGoldMax C2 decoy traffic\r\nAs detailed above, GoldMax employs decoy traffic to blend in with normal network traffic. Below are several examples\r\ndemonstrating the patterns GoldMax uses to mix legitimate traffic with C2 queries:\r\n185[.]225[.]69[.]69 C2 decoys “onetechcompany” C2 decoys “reyweb” C2 decoys\r\nhxxps[:]//cdn[.]mxpnl[.]com/ hxxps[:]//code[.]jquery[.]com/ hxxps[:]//code[.]jquery[.]com/\r\nhxxps[:]//code[.]jquery[.]com/ hxxps[:]//play[.]google[.]com/log?” hxxps[:]//cdn[.]cloudflare[.]com\r\nhxxps[:]//cdn[.]google[.]com/ hxxps[:]//fonts[.]gstatic[.]com/s/font.woff2″ hxxps[:]//cdn[.]google[.]com/\r\nhxxps[:]//fonts[.]gstatic[.]com/s/font.woff2 hxxps[:]//cdn[.]google[.]com/ hxxps[:]//cdn[.]jquery[.]com/\r\nhxxps[:]//ssl[.]gstatic[.]com/ui/v3/icons hxxps[:]//www.gstatic[.]com/images/? hxxps[:]//cdn[.]mxpnl[.]com/\r\nhxxps[:]//www.gstatic[.]com/images/? hxxps[:]//onetechcompany [.]com/style.css hxxps[:]//ssl[.]gstatic[.]com/ui/v\r\nhxxps[:]//185[.]225[.]69[.]69/style.css hxxps[:]//onetechcompany [.]com/script.js hxxps[:]//reyweb[.]com/style.css\r\nhxxps[:]//185[.]225[.]69[.]69/script.js hxxps[:]//onetechcompany [.]com/icon.ico hxxps[:]//reyweb[.]com/script.js\r\nhxxps[:]//185[.]225[.]69[.]69/icon.ico hxxps[:]//onetechcompany [.]com/icon.png hxxps[:]//reyweb[.]com/icon.ico\r\nhxxps[:]//185[.]225[.]69[.]69/icon.png\r\nhxxps[:]//onetechcompany\r\n[.]com/scripts/jquery.js\r\nhxxps[:]//reyweb[.]com/icon.png\r\nhxxps[:]//185[.]225[.]69[.]69/scripts/jquery.js\r\nhxxps[:]//onetechcompany\r\n[.]com/scripts/bootstrap.js\r\nhxxps[:]//reyweb[.]com/scripts/j\r\nhxxps[:]//185[.]225[.]69[.]69/scripts/bootstrap.js\r\nhxxps[:]//onetechcompany\r\n[.]com/css/style.css\r\nhxxps[:]//reyweb[.]com/scripts/b\r\nhxxps[:]//185[.]225[.]69[.]69/css/style.css\r\nhxxps[:]//onetechcompany\r\n[.]com/css/bootstrap.css\r\nhxxps[:]//reyweb[.]com/css/style\r\nhxxps[:]//185[.]225[.]69[.]69/css/bootstrap.css   hxxps[:]//reyweb[.]com/css/boot\r\nC2 decoy traffic added April 15, 2021:\r\n“megatoolkit” C2 decoys “nikeoutletinc” C2 decoys\r\nhttps://cdn.mxpnl.com/ https://cdn.mxpnl.com/\r\nhttps://www.google-analytics.com/ https://cdn.bootstrap.com/\r\nhttps://cdn.jquery.com/ https://www.google-analytics.com/\r\nhttps://cdn.cloudflare.com/ https://play.google.com/log?\r\nhttps://code.jquery.com/ https://cdn.jquery.com/\r\nhttps://play.google.com/log? https://code.jquery.com/\r\nhttps://megatoolkit.com/style.css https://nikeoutletinc.org/style.css\r\nhttps://megatoolkit.com/script.js https://nikeoutletinc.org/script.js\r\nhttps://megatoolkit.com/icon.ico https://nikeoutletinc.org/icon.ico\r\nhttps://megatoolkit.com/icon.png https://nikeoutletinc.org/icon.png\r\nhttps://www.microsoft.com/security/blog/2021/03/04/goldmax-goldfinder-sibot-analyzing-nobelium-malware\r\nPage 12 of 16\n\nhttps://megatoolkit.com/scripts/jquery.js https://nikeoutletinc.org/scripts/jquery.js\r\nhttps://megatoolkit.com/scripts/bootstrap.js https://nikeoutletinc.org/scripts/bootstrap.js\r\nhttps://megatoolkit.com/css/style.css https://nikeoutletinc.org/css/style.css\r\nhttps://megatoolkit.com/css/bootstrap.css https://nikeoutletinc.org/css/bootstrap.css\r\nAdvanced hunting queries\r\nRundll32.exe .sys image loads by reference\r\nLooks for rundll32.exe loading .sys file explicitly by name.\r\nRun query in Microsoft 365 security center:\r\nDeviceImageLoadEvents\r\n| where InitiatingProcessFileName =~ 'rundll32.exe'\r\n| where InitiatingProcessCommandLine has_any('.sys,','.sys ')\r\n| where FileName endswith '.sys'\r\n| project Timestamp, DeviceId, InitiatingProcessParentFileName, InitiatingProcessFolderPath,\r\nInitiatingProcessFileName, InitiatingProcessCommandLine, FolderPath, FileName\r\nRundll32.exe executing inline VBScript\r\nLooks for rundll32.exe executing specific inline VBScript commands.\r\nRun query in Microsoft 365 security center:\r\nDeviceProcessEvents\r\n| where FileName =~ 'rundll32.exe'\r\n| where ProcessCommandLine has 'Execute'\r\nand ProcessCommandLine has 'RegRead'\r\nand ProcessCommandLine has 'window.close'\r\n| project Timestamp, DeviceId, InitiatingProcessParentFileName, InitiatingProcessFileName,\r\nInitiatingProcessCommandLine, FileName, ProcessCommandLine\r\nRun query in Azure Sentinel (Github link):\r\nSecurityEvent\r\n| where EventID == 4688\r\n| where Process =~ 'rundll32.exe'\r\n| where CommandLine has_all ('Execute','RegRead','window.close')\r\n| project TimeGenerated, Computer, Account, Process, NewProcessName, CommandLine, ParentProcessName,\r\n_ResourceId\r\nVBScript payload stored in registry\r\nLooks for VBScript payload stored in registry, specifically stored within a sub-key of CurrentVersion registry path and\r\nexcluding common AutoRun persistence locations like Run and RunOnce registry keys.\r\nRun query in Microsoft 365 security center\r\nhttps://www.microsoft.com/security/blog/2021/03/04/goldmax-goldfinder-sibot-analyzing-nobelium-malware\r\nPage 13 of 16\n\nDeviceRegistryEvents\r\n| where RegistryKey endswith @'\\Microsoft\\Windows\\CurrentVersion'\r\n| where RegistryValueType == 'String'\r\n| where strlen(RegistryValueData) \u003e= 200\r\n| where RegistryValueData has_any('vbscript','jscript','mshtml,','mshtml\r\n','RunHTMLApplication','Execute(','CreateObject','RegRead','window.close')\r\n| where RegistryKey !endswith @'\\Software\\Microsoft\\Windows\\CurrentVersion\\Run'\r\nand RegistryKey !endswith @'\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce'\r\n| project Timestamp, DeviceId, InitiatingProcessFileName, InitiatingProcessCommandLine, RegistryKey,\r\nRegistryValueName, RegistryValueData\r\nRun query in Azure Sentinel (Github link):\r\nlet cmdTokens0 = dynamic(['vbscript','jscript']);\r\nlet cmdTokens1 = dynamic(['mshtml','RunHTMLApplication']);\r\nlet cmdTokens2 = dynamic(['Execute','CreateObject','RegRead','window.close']);\r\nSecurityEvent\r\n| where TimeGenerated \u003e= ago(14d)\r\n| where EventID == 4688\r\n| where CommandLine has @'\\Microsoft\\Windows\\CurrentVersion'\r\n| where not(CommandLine has_any (@'\\Software\\Microsoft\\Windows\\CurrentVersion\\Run',\r\n@'\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce'))\r\n// If you are receiving false positives, then it may help to make the query more strict by uncommenting the\r\nlines below to refine the matches\r\n//| where CommandLine has_any (cmdTokens0)\r\n//| where CommandLine has_all (cmdTokens1)\r\n| where CommandLine has_all (cmdTokens2)\r\n| project TimeGenerated, Computer, Account, Process, NewProcessName, CommandLine, ParentProcessName,\r\n_ResourceId\r\nDomain IOC lookup\r\nLooks for identified C2 domains.\r\nRun query in Azure Sentinel (GitHub link)\r\nlet DomainNames = dynamic(['onetechcompany.com', 'reyweb.com', 'srfnetwork.org']);\r\nlet IPList = dynamic(['185.225.69.69']);\r\nlet IPRegex = '[0-9]{1,3}\\\\.[0-9]{1,3}\\\\.[0-9]{1,3}\\\\.[0-9]{1,3}';\r\n(union isfuzzy=true\r\n(CommonSecurityLog\r\nhttps://www.microsoft.com/security/blog/2021/03/04/goldmax-goldfinder-sibot-analyzing-nobelium-malware\r\nPage 14 of 16\n\n| where SourceIP in (IPList) or DestinationIP in (IPList) or DestinationHostName in~ (DomainNames) or\r\nRequestURL has_any (DomainNames) or Message has_any (IPList)\r\n| parse Message with * '(' DNSName ')' *\r\n| extend MessageIP = extract(IPRegex, 0, Message)\r\n| extend IPMatch = case(SourceIP in (IPList), \"SourceIP\", DestinationIP in (IPList), \"DestinationIP\",\r\nMessageIP in (IPList), \"Message\", RequestURL in (DomainNames), \"RequestUrl\", \"NoMatch\")\r\n| extend timestamp = TimeGenerated, IPCustomEntity = case(IPMatch == \"SourceIP\", SourceIP, IPMatch ==\r\n\"DestinationIP\", DestinationIP, IPMatch == \"Message\", MessageIP, \"NoMatch\"), AccountCustomEntity =\r\nSourceUserID\r\n),\r\n(DnsEvents\r\n| where IPAddresses in (IPList) or Name in~ (DomainNames)\r\n| extend DestinationIPAddress = IPAddresses, DNSName = Name, Host = Computer\r\n| extend timestamp = TimeGenerated, IPCustomEntity = DestinationIPAddress, HostCustomEntity = Host\r\n),\r\n(VMConnection\r\n| where SourceIp in (IPList) or DestinationIp in (IPList) or RemoteDnsCanonicalNames has_any (DomainNames)\r\n| parse RemoteDnsCanonicalNames with * '[\"' DNSName '\"]' *\r\n| extend IPMatch = case( SourceIp in (IPList), \"SourceIP\", DestinationIp in (IPList), \"DestinationIP\",\r\n\"None\")\r\n| extend timestamp = TimeGenerated, IPCustomEntity = case(IPMatch == \"SourceIP\", SourceIp, IPMatch ==\r\n\"DestinationIP\", DestinationIp, \"NoMatch\"), HostCustomEntity = Computer\r\n),\r\n(OfficeActivity\r\n| where ClientIP in (IPList)\r\n| extend timestamp = TimeGenerated, IPCustomEntity = ClientIP, AccountCustomEntity = UserId\r\n),\r\n(DeviceNetworkEvents\r\n| where RemoteUrl has_any (DomainNames) or RemoteIP in (IPList)\r\n| extend timestamp = TimeGenerated, DNSName = RemoteUrl, IPCustomEntity = RemoteIP, HostCustomEntity =\r\nDeviceName\r\n),\r\n(AzureDiagnostics\r\n| where ResourceType == \"AZUREFIREWALLS\"\r\n| where Category == \"AzureFirewallDnsProxy\"\r\n| parse msg_s with \"DNS Request: \" ClientIP \":\" ClientPort \" - \" QueryID \" \" Request_Type \" \" Request_Class \"\r\n\" Request_Name \". \" Request_Protocol \" \" Request_Size \" \" EDNSO_DO \" \" EDNS0_Buffersize \" \" Responce_Code \" \"\r\nhttps://www.microsoft.com/security/blog/2021/03/04/goldmax-goldfinder-sibot-analyzing-nobelium-malware\r\nPage 15 of 16\n\nResponce_Flags \" \" Responce_Size \" \" Response_Duration\r\n| where Request_Name has_any (DomainNames)\r\n| extend timestamp = TimeGenerated, DNSName = Request_Name, IPCustomEntity = ClientIP\r\n),\r\n(AzureDiagnostics\r\n| where ResourceType == \"AZUREFIREWALLS\"\r\n| where Category == \"AzureFirewallApplicationRule\"\r\n| parse msg_s with Protocol 'request from ' SourceHost ':' SourcePort 'to ' DestinationHost ':'\r\nDestinationPort '. Action:' Action\r\n| where isnotempty(DestinationHost)\r\n| where DestinationHost has_any (DomainNames)\r\n| extend timestamp = TimeGenerated, DNSName = DestinationHost, IPCustomEntity = SourceHost\r\n)\r\n)\r\nSource: https://www.microsoft.com/security/blog/2021/03/04/goldmax-goldfinder-sibot-analyzing-nobelium-malware\r\nhttps://www.microsoft.com/security/blog/2021/03/04/goldmax-goldfinder-sibot-analyzing-nobelium-malware\r\nPage 16 of 16", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia", "MISPGALAXY" ], "references": [ "https://www.microsoft.com/security/blog/2021/03/04/goldmax-goldfinder-sibot-analyzing-nobelium-malware" ], "report_names": [ "goldmax-goldfinder-sibot-analyzing-nobelium-malware" ], "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": "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": 1775434341, "ts_updated_at": 1775792253, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/0cb3ea6f074bb99db8727913700a58932ac664be.pdf", "text": "https://archive.orkl.eu/0cb3ea6f074bb99db8727913700a58932ac664be.txt", "img": "https://archive.orkl.eu/0cb3ea6f074bb99db8727913700a58932ac664be.jpg" } }