{"id":93028,"date":"2021-03-04T09:00:02","date_gmt":"2021-03-04T17:00:02","guid":{"rendered":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/\/?p=93028"},"modified":"2024-02-06T17:10:35","modified_gmt":"2024-02-07T01:10:35","slug":"goldmax-goldfinder-sibot-analyzing-nobelium-malware","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/2021\/03\/04\/goldmax-goldfinder-sibot-analyzing-nobelium-malware\/","title":{"rendered":"GoldMax, GoldFinder, and Sibot: Analyzing NOBELIUM\u2019s layered persistence"},"content":{"rendered":"\n\nApril 2023 update<\/strong> \u2013 Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. NOBELIUM is now tracked as Midnight Blizzard<\/a><\/strong>.<\/em>\n\n<\/em>\n\nApril 15, 2021 update – <\/strong>We updated this blog with new indicators of compromise, including files<\/a>, domains<\/a>, and C2 decoy traffic<\/a>, released by Cybersecurity & Infrastructure Security Agency (CISA) in Malware Analysis Report MAR-10327841-1.v1 \u2013 SUNSHUTTLE<\/a>.\u00a0\u00a0<\/em>\n\nMicrosoft continues to work with partners and customers to expand our knowledge of the threat actor behind the nation-state cyberattacks<\/a> that compromised the supply chain of SolarWinds and impacted multiple other organizations. As we have shared previously, we have observed the threat actor using both backdoor and other malware implants to establish sustained access to affected networks. As part of our commitment to transparency and intelligence-sharing in the defender community, we continue to update analysis and investigative resources<\/a> as we discover new tactics and techniques used by the threat actor.\n

Introducing NOBELIUM<\/h2>\nMicrosoft Threat Intelligence Center (MSTIC) is naming the actor behind the attacks against SolarWinds, the SUNBURST backdoor, TEARDROP malware, and related components as NOBELIUM.\n\nRecent investigations have identified three new pieces of malware being used in late-stage activity by NOBELIUM. This blog provides detailed analysis of these malware strains to help defenders detect, protect, and respond to this threat. We continue to partner with FireEye to understand these threats and protect our mutual customers. FireEye\u2019s analysis of the malware used by NOBELIUM is here<\/a>.\n\nMicrosoft discovered these new attacker tools and capabilities in some compromised customer networks and observed them to be in use from August to September 2020. Further analysis has revealed these may have been on compromised systems as early as June 2020. These tools are new pieces of malware that are unique to this actor. They are tailor-made for specific networks and are assessed to be introduced after the actor has gained access through compromised credentials or the SolarWinds binary and after moving laterally with TEARDROP and other hands-on-keyboard actions.\n\nThese capabilities differ from previously known NOBELIUM tools and attack patterns, and reiterate the actor\u2019s sophistication. In all stages of the attack, the actor demonstrated a deep knowledge of software tools, deployments, security software and systems common in networks, and techniques frequently used by incident response teams. This knowledge is reflected in the actor\u2019s operational decisions, from the choice of command-and-control (C2) infrastructure to the naming of scheduled tasks used to maintain persistence.\n\nWith this actor\u2019s established pattern of using unique infrastructure and tooling for each target, and the operational value of maintaining their persistence on compromised networks, it is likely that additional components will be discovered as our investigation into the actions of this threat actor continues.\n

New NOBELIUM malware<\/h2>\nMaintaining persistence is critical for any threat actor after gaining access to a network. In addition to the backdoor in the SolarWinds software, NOBELIUM has been observed using stolen credentials to access cloud services like email and storage, as well as compromised identities to gain and maintain access to networks via virtual private networks (VPNs) and remote access tools. Microsoft assesses that the newly surfaced pieces of malware were used by the actor to maintain persistence and perform actions on very specific and targeted networks post-compromise, even evading initial detection during incident response.\n

GoldMax<\/h2>\nThe GoldMax malware was discovered persisting on networks as a scheduled task impersonating systems management software. In the instances it was encountered, the scheduled task was named after software that existed in the environment, and pointed to a subfolder in ProgramData named after that software, with a similar executable name. The executable, however, was the GoldMax implant.\n\nWritten in Go, GoldMax acts as command-and-control backdoor for the actor. It uses several different techniques to obfuscate its actions and evade detection. The malware writes an encrypted configuration file to disk, where the file name and AES-256 cipher keys are unique per implant and based on environmental variables and information about the network where it is running.\n\nGoldMax establishes a secure session key with its C2 and uses that key to securely communicate with the C2, preventing non-GoldMax-initiated connections from receiving and identifying malicious traffic. The C2 can send commands to be launched for various operations, including native OS commands, via psuedo-randomly generated cookies. The hardcoded cookies are unique to each implant, appearing to be random strings but mapping to victims and operations on the actor side.\n\nObserved GoldMax C2 domains are high-reputation and high-prevalence, often acquired from domain resellers so that Whois records retain the creation date from their previous registration, or domains that may have been compromised. This tactic complements NOBELIUM\u2019s operational security strategy as these domains are more likely to be overlooked by security products and analysts based on their perceived long-lived domain ownership. Put simply, several domains we have shared as GoldMax C2 domains are only associated with NOBELIUM after the time they were re-sold or compromised \u2013 and Microsoft has provided that indicator context where it is available to us.\n\nUpon execution, GoldMax retrieves a list of the system\u2019s network interfaces; the malware terminates if it is unable to do so or no network interface is configured. It then attempts to determine if any of the network interfaces has the following hardcoded MAC address: c8:27:cc:c2:37:5a<\/em>. If so, it terminates.\n

\"\"<\/p>\n

Figure <\/em>1<\/em>. HardwareAddr.String() call, hardcoded MAC address, and os.Exit() call<\/em><\/p>\n\n

Configuration file<\/h3>\nGoldMax is designed to store its configuration data in an encrypted file named features.dat.tmp<\/em>. The file name varies in different versions of GoldMax, but in all observed variants, the configuration file carries a .tmp<\/em> file extension and is located in the same directory as GoldMax. The first time GoldMax is run, it uses a set of embedded default values to create and populate its configuration file on disk. The next time GoldMax \u00a0runs, instead of using its embedded configuration data, it loads the configuration data from its configuration file stored on the file system.\n\nThe data from the configuration file typically matches the default configuration data embedded in GoldMax, since the embedded data was initially used to create the configuration file. However, GoldMax comes with a command-and-control feature that allows its operators to dynamically update its configuration data on the fly. When this happens, GoldMax overwrites the existing data in its configuration file with the new configuration data received from its operators, so the next time GoldMax is run, it uses the most up-to-date version of its configuration data to initialize its runtime settings.\n\nThe configuration data is encrypted using the AES-256 encryption algorithm, CFB encryption mode, and the following cipher key: 4naehrkz5alao2jd035zjh3j1v1dvyyc<\/em> (key varies in different versions of GoldMax). The AES encrypted configuration data is then Base64-encoded using the custom Base64 alphabet \u201cABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_<\/em>\u201d before it is stored in the configuration file on the file system. When run, GoldMax decodes (Base64) and decrypts (AES-256) the configuration data to reveal a custom data structure comprised of the following dynamically generated and hardcoded values (delimited by \u2018|\u2019):\n

\"\"<\/p>\n

Figure <\/em>2<\/em>. Data structure of the GoldMax configuration data<\/em><\/p>\nGoldMax proceeds to parse the data structure depicted above and uses the values within to initialize its runtime settings and variables used by its different components.\n\nIf the configuration file is not<\/em> present on the system, (i.e., the first time it runs), GoldMax uses dynamically generated and embedded values to create and populate the data structure depicted above. It then uses the same AES encryption methodology to encrypt the data structure. After encrypting the data structure, GoldMax proceeds to Base64 encode the encrypted data structure and removes all instances of \u2018=\u2019 from the Base64 encoded string. It then creates a configuration file on the file system (e.g., features.dat.tmp<\/em>) and stores the Base64 encoded data in the configuration file.\n

Activation date<\/h3>\nGoldMax\u2019s configuration data contains an execution activation\/trigger date, stored as an ASCII Unix\/Epoch time value as shown in the configuration data section above, that is essentially meant to function as an \u201cactivate after x date\/time\u201d feature. After loading its configuration data, GoldMax checks the current date-time value of the compromised system against the activation date from the configuration data.\n

\"\"<\/p>\n

Figure <\/em>3<\/em>. Inline Unix() function and EPOCH comparison of the current and activation date\/time <\/em><\/p>\nIf an activation date-time value is specified in the configuration data (i.e., not set to \u20180<\/em>\u2019) and the activation date-time occurs on or before the current date-time of the compromised system, GoldMax commences its malicious activities. Otherwise, GoldMax terminates and continues to do so until the activation date is reached. If no activation date is specified in the configuration data (i.e., field set to \u20180<\/em>\u2019), the malware commences its malicious activities straightaway.\n\nIn all versions of GoldMax analyzed during our investigation, the activation date is initially set to \u20180<\/em>\u2019. However, through its command-and-control feature, the operators can dynamically update the activation date using a specific C2 command, in which case the new activation date is stored in the configuration file and is checked each time GoldMax runs.\n

Decoy network traffic<\/h3>\nGoldMax is equipped with a decoy network traffic generation feature that allows it to surround its malicious network traffic with seemingly benign traffic. This feature is meant to make distinguishing between malicious and benign traffic more challenging. If the decoy network traffic feature is enabled (set to \u20181<\/em>\u2019 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 names and\/or IP addresses. The exact URL for each request is pseudo-randomly selected from a list of 14 hardcoded URLs. An example URL list comprised of 14 legitimate and C2 URLs is shown below:\n

\"\"<\/p>\n

Figure <\/em>4<\/em>. Hardcoded URLs from which GoldMax selects up to four to issue HTTP requests for<\/em><\/p>\nAs shown above, some of the decoy URLs point to the domain name of the actual C2 (e.g., onetechcompany[.]com<\/em>). However, the particular HTTP resources referenced in the URLs above (e.g., style.css<\/em>, script.js<\/em>, icon.ico<\/em>, etc.) are known to the C2 as being decoy resources that serve no role in the regular C2 communication between GoldMax and its C2.\n\nThe Referer value for each decoy HTTP request is also pseudo-randomly selected from a list of four legitimate domain names. For example, we have seen the following in various combinations to make up lists of four domains: www[.]mail[.]com<\/em>, www[.]bing[.]com<\/em>, www[.]facebook[.]com<\/em>, www[.]google[.]com<\/em>, www[.]twitter[.]com<\/em>, www[.]yahoo[.]com<\/em>, etc. For demonstration purposes, an example decoy HTTP GET request is included below (the Connection and User-Agent HTTP headers and their values are manually added to each request by GoldMax and remain the same across all decoy HTTP requests, regardless of the destination URL):\n

\"\"<\/p>\n

Figure <\/em>5<\/em>. Sample decoy HTTP GET request <\/em><\/p>\n\n

RSA session key<\/h3>\nThe next step in the execution cycle involves establishing a secure session key between GoldMax and its C2 server. GoldMax first requests a session key from its C2 server by sending an HTTP GET request that contains a custom HTTP Cookie value that is unique to each implant. The Cookie value is comprised of the following dynamically generated and hardcoded values:\n

\"\"<\/p>\n

Figure <\/em>6<\/em>. HTTP Cookie value in HTTP GET request <\/em><\/p>\nAn example request containing the custom Cookie value is shown below:\n

\"\"<\/p>\n

Figure <\/em>7<\/em>. Sample HTTP GET request with the custom Cookie value<\/em><\/p>\nThe User-Agent and Connection values above are hardcoded in the HTTP request. The Referer value is pseudo-randomly selected from a list of four legitimate domain names using various combinations of the following: www[.]mail[.]com<\/em>, www[.]bing[.]com<\/em>, www[.]facebook[.]com<\/em>, www[.]google[.]com<\/em>, www[.]twitter[.]com<\/em>, www[.]yahoo[.]com<\/em>, etc.\n\nIn response to the request above, GoldMax expects to receive an HTTP 200 response containing a very specific and hardcoded ASCII string (e.g., \u201cuFLa12nFmKkjrmjj<\/em>\u201d). The seemingly random-looking string is typically 10-16 bytes long (after all leading and trailing white space has been removed). It can best be described as a \u201cshared secret\u201d between the C2 and each individual implant (the string varies in different versions of GoldMax). It serves as an acknowledgement that the C2 server has received GoldMax\u2019s request for a new a session key. If GoldMax does not receive the expected string, it sleeps for a random amount of time and repeats (indefinitely) the process described above to obtain the expected string from its C2 server, or until the GoldMax process is terminated.\n\nAfter receiving the expected string, GoldMax sleeps for up to 14 seconds before proceeding. If the decoy traffic option is enabled in the configuration data, GoldMax issues a pseudo-random number of HTTP GET requests (as described under the decoy network traffic section above). GoldMax then issues a new HTTP GET request to its C2 server containing a new set of hardcoded Cookie values.\n

\"\"<\/p>\n

Figure <\/em>8<\/em>. Sample HTTP GET request showing hardcoded Cookie values<\/em><\/p>\nThe only observed difference between the first and second HTTP GET requests is the value of the second Cookie highlighted above (example values: iC0Pf2a48<\/em> from the first request vs. J4yeUYKyeuNa2<\/em> from the second request above). In response to the request, GoldMax receives an encrypted RSA session key (Base64-encoded). Each version of GoldMax contains an RSA private key which GoldMax proceeds to decode (using pem.Decode()<\/em>) and parse (using x509.ParsePKCS1PrivateKey()<\/em>). GoldMax uses rsa.DecryptOAEP()<\/em> with the parsed private key to decrypt (using RSA-OAEP) the RSA-encrypted session key received from its C2 server. From this point on, the session key is used to encrypt data sent between GoldMax and its C2 server.\n

C2 commands<\/h3>\nAfter establishing a session key, GoldMax reaches out to its C2 server to receive, decrypt (AES-256), parse, and execute commands. To retrieve an encrypted C2 command from its C2 server, GoldMax sends an HTTP GET request. This HTTP GET request only contains a single Cookie value, which matches the Cookie value used during the session key establishment process (the User-Agent and Connection headers and values are hardcoded, as before):\n

\"\"<\/p>\n

Figure <\/em>9<\/em>. Sample HTTP GET request containing a single Cookie value<\/em><\/p>\nIn response to the request above, GoldMax receives an encrypted (AES-256) and encoded (Base64 using custom Base64 alphabet) C2 command. The command is encrypted using the session key established between GoldMax and its C2 server. After decoding and decrypting the C2 command, GoldMax proceeds to parse the C2 command.\n\nC2 commands are represented as seemingly random alphanumerical ASCII strings (e.g., \u201cKbwUQrcooAntqNMddu4XRj<\/em>\u201d) that are unique to each implant but known to the C2 server. The C2 commands allow the operator to download and execute files on the compromised system, upload files from the compromised system to the C2 server, execute OS commands on the compromised system, spawn a command shell, and dynamically update GoldMax\u2019s configuration data. These dynamic updates 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.\n\nIt is worth noting that all observed versions of GoldMax were compiled with the Go compiler version 1.14.2 (released in April 2020). In all observed versions, the main Go source code file for GoldMax was located under the following directory: \/var\/www\/html\/builds\/<\/em>. The Go packages and libraries used during the compilation process of GoldMax were mostly located under the \/var\/www\/html\/go\/src\/<\/em> directory (e.g., \/var\/www\/html\/go\/src\/net\/http\/http.go<\/em>).\n

Sibot<\/h2>\nSibot is a dual-purpose malware implemented in VBScript<\/a>. It is designed to achieve persistence on the infected machine then download and execute a payload from a remote C2 server. \u00a0The VBScript file is given a name that impersonates legitimate Windows tasks and is either stored in the registry of the compromised system or in an obfuscated format on disk. The VBScript is then run via a scheduled task.\n\nSibot reaches out to a legitimate but compromised website to download a DLL to a folder under System32<\/em>. In observed instances the DLL is downloaded to C:\\windows\\system32\\drivers\\<\/em>, renamed with a .sys<\/em> extension, and then executed by rundll32<\/em>. The scheduled task calls an MSHTA application to run Sibot via the obfuscated script. This simplistic implementation allows for a low footprint for the actor, as they can download and run new code without changes to the compromised endpoint by just updating the hosted DLL. The compromised website used to host the DLL is different for every compromised network and includes websites of medical device manufacturers and IT service providers.\n\nWe have observed three variants of this malware, all of which are obfuscated:\n