AIS Protects Customers Against Sophisticated SolarMarker Malware

Authors: Jacob Hartman and Patrick McHarris

Key Takeaways

  • Assured Information Security (AIS) has discovered a campaign targeting users of AIS’s security products, particularly Metasponse, AIS’s incident response framework.
  • The campaign utilizes Search Engine Optimization (SEO) poisoning to manipulate search results to point to pages containing malicious document/binary downloads.
  • The payload contains numerous similarities to the SolarMarker group and shows a high level of sophistication.


AIS regularly monitors the public web for leaks of AIS products and possible threats to AIS customers. This has paid off in the discovery of targeted SEO poisoning attacks against users of AIS products, mainly the Metasponse incident response framework. This article shows AIS’s analysis of this threat.

SEO Poisoning and Google Groups

Searching for “metasponse” or “metasponse download” returns several legitimate pages, such as AIS’s own page on Metasponse and academic papers referring to it. However, there are some that do not appear so legitimate:

Many times, these are in the first page of results mixed in with legitimate search results. One of the discovered fake search results pointed to a Google Groups conversations containing SEO manipulative content. By utilizing a known good service (Google Groups) to push their content, adversaries hope to bypass web content filtering on enterprise and government networks. Thankfully, by the time of writing this article, at least one of these has been banned:

However, at least one group remains. The group appears to have failed to gain sufficient traffic and has remained, at the time of writing, under the radar. This allows us to see how the content in these groups is organized:

These pages contain very large and noticeable images, prompting the user to click them to download the file they want.

These links put the user through numerous redirects until they are provided a document or executable file.

Malicious Downloads

When a user clicks on the presented link, they are redirected multiple times, and if the user’s system matches what the attacker is trying to target, the user will be provided a document to download. Files observed downloaded include executables, PDFs, and Microsoft Office documents (docx).

.NET Dropper

One file that the AIS team was able to download was an executable called Improving-Er-Patient-Satisfaction.exe. A quick analysis showed the file to be a heavily obfuscated .NET executable. Automated dynamic analysis did not initially show many results. The binary was analyzed statically by decompiling it to view the obfuscated code. Features of the obfuscated code included all numbers being converted to randomly named functions that returned the number:

Another feature was the functions being stuffed with useless code that just increments a number without doing anything else of interest:

Certain functions returned obfuscated strings with each character subtracted with a number passed to the decoding function. The code for the decode function was copied out and run with Dotnet Core, which allows not only execution on Linux, but quick script-like execution with the “dotnet run” command. Using this manual method, the AIS team was able to decode the following strings:

  • System.Management.Automation.PowerShell
  • Create
  • Invoke
  • CyFwve.exe
  • /s
  • AddScript

The CyFwve.exe referenced is an installer for PDF Merge, which is stored encoded in the binary itself. This is dropped as a “smokescreen” to hide the other malicious activity and distract the user. Also, as can be guessed from these strings, the binary calls PowerShell by using the System.Management.Automation.dll method. .NET code can load this DLL and execute PowerShell directly in its own process. This allows the attacker to execute PowerShell without calling the actual PowerShell binary directly, allowing the attacker to bypass any protections that defenders put on the PowerShell binary. The PowerShell script called is also stored encrypted in the binary itself using a XOR with a key also present in the binary. The key in this sample was:


PowerShell Script

The PowerShell script serves to install the final payload onto the system. It creates a shortcut (LNK) file in the user’s startup folder, enabling persistence whenever the user logs on to the infected system.

Interestingly, the DLL is not directly loaded by the shortcut, but by creating an encrypted payload with a randomized file extension. The PowerShell script then registers the file extension to run with another smaller PowerShell script that unencrypts and loads the payload.

Created encrypted DLL:

Extension handler in the registry:

The AIS team was able to manually extract and decode the final payload (thanks to CyberChef!) to continue the analysis.

It’s the Final Payload! (dadada, dadadadada)

This payload is another .NET binary, this time a DLL that is loaded into the PowerShell process through a decryptor/loader:

This loader is both used as the handler for the randomized extension as well as during the initial execution of the sample.

Dissecting the Code

Once again, this payload is a heavily obfuscated .NET binary. All strings are stored in functions that reconstruct the values from either two XOR-ed byte arrays or a series of integers subtracted together and appended together.

Like the previous .NET sample, the string functions were copied and could be safely executed using Dotnet Core to reveal what values they hold.

Not all of the functions appeared to hold valid strings, with some containing binary data in functions that are never called. These appear to be garbage functions made to confuse analysis and waste time. The code is also littered with execution-time consuming threads and sleeps to make analysis, both static and dynamic, more difficult.

Extracting Functionality

Once the strings were decoded, the team could get a better idea of how the payload operates. Like other samples of SolarMarker, command and control (C2) communications are done through passing encrypted data over HTTP (note not HTTPS, but HTTP containing encrypted data). RSA is used to encrypt a generated AES key to send the C2 server, which is used afterwards to both encrypt and decrypt communicated data.

AES key being generated (Note that function names and fields have been changed to make the code more readable):

Key being encrypted with RSA:


TTP Indicators

  • Randomly named LNK files in user startup folders.
  • Long and randomly named file extension name handlers created on a system
  • Monitor for the temporary files created when PowerShell dynamically loads C# code, such as the .cs and .dll files created in the user’s temporary directory.


  • Improving-Er-Patient-Satisfaction.exe SHA1: 4732d62c289ab07348da87a3c3f72c11cb5dd6d2
  • CyFwve.exe SHA1: 2908846d8d17393e4ae9a620ff6e80d039b8c4ce
  • PowerShell Script SHA1: ff2a4ed76310ae6c0b9964bd21a306eb14174440
  • Final Payload SHA1: 5b5874d1bb711c6d34ab8b9f33aa1bd6625b2b6a

Network IOCs

  • C2 Server: 86[.]106[.]20[.]155

C2 traffic is sent in a JSON format, with requests to the C2 server having the following structure:

{“action”:”ping”,”hwid”:”<HWID>”,”pc_name”:”<HOSTNAME>”,”os_name”:”Win<OS_NAME>”,”arch”:”<ARCH>”,”rights”:”<+|->”,”version”:”AP_3/B”,”workgroup”:”? | ?”,”dns”:0,”protocol_version”:2}

This data format indicates a few things:

  • The payload is a newer version than of other samples seen before. Other articles have contained versions AP_2.
  • Continuous development is clearly being done, given the placeholder values for workgroup and a protocol version field.
  • Linux support doesn’t seem to be a priority, given the “Win” hardcoded into the os_name field.

AIS determined that the payload supports a couple of commands, which allow the implant to write files and execute binaries and PowerShell scripts:

  • file: Supports writing executables to a randomized name in the temp directory or PowerShell scripts, then executing the file or script.
  • command: Executes a command using PowerShell.

Given this limited set of functionalities, it can be assumed that this implant is mainly for establishing a presence on a network and to serve to execute further implants and reconnaissance commands.


In conclusion, this sample can be attributed to the SolarMarker APT group with a high degree of certainty, as its attack techniques and sample version string matching known SolarMarker activities. With the high levels of obfuscation and anti-forensics techniques, this sample clearly attempts to deter detection and shows the developer has significant resources behind them. This sample appears to be made to gain a foothold in a network but given this sample attempts to imitate government and military documents, this foothold would be all this advanced threat needs to perform grave damage against critical targets.

AIS customers should be vigilant for attacks of this type, and only access documentation and other product data from known AIS sources. For information on the proper channels of getting AIS products or to learn more about what services AIS provides, contact us here.

Privacy Settings
We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
Consent to display content from Youtube
Consent to display content from Vimeo
Google Maps
Consent to display content from Google
Consent to display content from Spotify
Sound Cloud
Consent to display content from Sound