By Warren Mercer, Paul Rascagneres and Vitor Ventura with contributions from Eric Kuhla.

Updated Jan. 17, 2020: the documents do not exploit the CVE-2017-0199 vulnerability.

Executive Summary Today, Cisco Talos is unveiling the details of a new RAT we have identified we're calling "JhoneRAT." This new RAT is dropped to the victims via malicious Microsoft Office documents. The dropper, along with the Python RAT, attempts to gather information on the victim's machine and then uses multiple cloud services: Google Drive, Twitter, ImgBB and Google Forms. The RAT attempts to download additional payloads and upload the information gathered during the reconnaissance phase. This particular RAT attempts to target a very specific set of Arabic-speaking countries. The filtering is performed by checking the keyboard layout of the infected systems. Based on the analysed sample, JhoneRAT targets Saudi Arabia, Iraq, Egypt, Libya, Algeria, Morocco, Tunisia, Oman, Yemen, Syria, UAE, Kuwait, Bahrain and Lebanon.

What's new? The campaign shows an actor that developed a homemade RAT that works in multiple layers hosted on cloud providers. JhoneRAT is developed in Python but not based on public source code, as it is often the case for this type of malware. The attackers put great effort to carefully select the targets located in specific countries based on the victim's keyboard layout.

How did it work? Everything starts with a malicious document using a well-known vulnerability to download a malicious document hosted on the internet. For this campaign, the attacker chose to use a cloud provider (Google) with a good reputation to avoid URL blocklisting. The malware is divided into a couple of layers — each layer downloads a new payload on a cloud provider to get the final RAT developed in Python and that uses additional providers such as Twitter and ImgBB.

So what? This RAT is a good example of how a highly focused attack that tries to blend its network traffic into the crowd can be highly effective. In this campaign, focusing detection of the network is not the best approach. Instead, the detection must be based on the behaviour on the operating system. Attackers can abuse well-known cloud providers and abuse their reputations in order to avoid detection.

Opsec and targeted countries
The fact that this attacker decided to leverage cloud services and four different services — and not their own infrastructure — is smart from an opsec point of view. It is hard for the targets to identify legitimate and malicious traffic to cloud provider infrastructure. Moreover, this kind of infrastructure uses HTTPS and the flow is encrypted that makes man-in-the-middle interception more complicated for the defender. It is not the first time an attacker used only cloud providers.

User-agent #1

User-agent #2

User-agent #3
Even while using these services, the authors of this JhoneRAT went further and used different user-agent strings depending on the request, and even on the downloaders the authors used other user-agent strings.

We already published a couple of articles about ROKRAT (here, here, here and here) where another unrelated actor, Group123, made the same choice but with different providers.

The attacker implemented filtering based on the keyboard's layout.

Keyboard layout check
The malware is executed only for the following layout, the country is based on the Microsoft website:

  • '0401' -> Saudi Arabia
  • '0801' -> Iraq
  • '0c01' -> Egypt
  • '1001' -> Libya
  • '1401' -> Algeria
  • '1801' -> Morocco
  • '1c01' -> Tunisia
  • '2001' -> Oman
  • '2401' -> Yemen
  • '2801' -> Syria
  • '3801' -> UAE
  • '3401' -> Kuwait
  • '3c01' -> Bahrain
  • '3001' -> Lebanon

Malicious documents

Decoy document
We identified three malicious Microsoft Office documents that download and load an additional Office document with a Macro. The oldest one from November 2019, named "Urgent.docx," is shown below:

Initial decoy document

The author of the document asks to enable editing in English and in Arabic.

The second document from the beginning of January is named "fb.docx" and contains usernames and passwords from an alleged "Facebook" leak:

Second decoy document

The more recent document is from mid-January and alleged to be from a United Arab Emirate organization. The author blurred the content and asks the user to enable editing to see the content:

Third decoy document

Macro loading
In the three documents, an additional Office document containing a Macro is downloaded and executed.  The documents are located on Google Drive.

Malicious documents on Google Drive

Infection workflow

Stage No. 1: Malicious template on Google Drive
The template located on Google Drive contains a macro. The macro contains a virtual machine detection technique based on the serial number of the disks available in the victim environment. Indeed, some VMs do not have serial numbers and the macro is executed only if a serial number exists. A WMIC command is executed to get this information on the targeted system.

Macro WMI check

If a serial number exists, the rest of the code is executed. The purpose is to download an image from a new Google Drive link:

Image download

It is interesting to note that the filename of the downloaded image is randomly generated based on a dictionary: Array ("cartoon," "img," "photo"). The filename will be cartoon.jpg or img.jpg or photo.jpg and the image usually depicts a cartoon.

Stage No. 2: Image file on Google Drive
The image file is a real image with a base64-encoded binary appended at the end.

Image No. 1
The malware author has a curious sense of humor.

Image No. 2
The base64 data and image are separated by the "****" string:

Image and payload separation

The decoded binary filename is also randomly generated based on a dictionary: Array ("proc", "chrome", "winrar"). It can be proc.exe or chrome.exe or winrar.exe.

Stage No. 3: Autoit file
The decoded base64 data is an AutoIT binary. This binary downloads a new file on Google Drive.

AutoIT downloader

The filename is also randomly generated based on a dictionary $ARRAY[5]=["prc","winrar","chrome","sync","COM surr"].

Stage No. 4: Python RAT using cloud providers
The final payload is a remote access tool (RAT) written in Python. We named this RAT "JhoneRAT." The Python code is wrapped into an executable using pyinstaller. It uses minimal obfuscation applied only on variables and function naming.

RAT startup

The RAT starts by launching three threads. The first is responsible for checking if the system has the targeted keyboard layout — this is exclusively in Arabic-speaking countries. The second will create the persistence and, finally, the last one to be started is the main cycle for the RAT. As we explained before, the RAT targets specific countries by checking the keyboard's layout. In fact, this is one of the first checks it performs when it is executed. The persistence is achieved by adding an entry with the name "ChromeUpdater" to the 'Software\\Microsoft\\Windows\\CurrentVersion\\Run' .

Command and control communications
This RAT uses three different cloud services to perform all its command and control (C2) activities. It checks for new commands in the tweets from the handle @jhone87438316 (suspended by Twitter) every 10 seconds using the BeautifulSoup HTML parser to identify new tweets. These commands can be issued to a specific victim based on the UID generated on each target (by using the disk serial and contextual information such as the hostname, the antivirus and the OS) or to all of them:

Command fetching

Command parsing

The exfiltration, however, is done via other cloud providers. The screenshots are exfiltrated via the ImgBB website:

The remaining commands send feedback by posting data into Google Forms:

Finally, the RAT is able to download files encoded in base64 on Google Drive:

Feature-wise, the RAT has three commands:

  • Take a screenshot and upload it to ImgBB.
  • Download binary disguised has a picture from Google Drive and execute it.
  • Execute a command and send the output to Google Forms.

Anti-VM, anti-decompiler and no header
The attacker put a couple of tricks in place to avoid execution on virtual machines (sandbox). The first trick is the check of the serial number of the disk. The actor used the same technique in the macro and in the JhoneRAT. By default, most of the virtual machines do not have a serial number on the disk.

The attacker used a second trick to avoid analysis of the Python code. The actor used the same trick that FireEye in the Flare-On 6: Challenge 7: They removed the header of the Python bytecode. It can be perfectly executed without the header, but tools such as uncompyle6 need this header:

$ uncompyle6 final2

ImportError: Unknown magic number 227 in final2

Additionally, the generated code by uncompyle6 varies depending on the version and the impact is important.

Here is a condition generated with uncompyle6 version 3.3.5:

The same code generated with uncompyle6 version 3.6.2:

Based on our analysis and the behaviour of the executed malware, the correct interpretation is the first one based on the oldest version of uncompyle6.

For this specific condition, it is important because it's filtering on the keyboard layout to identify the targets.

This campaign shows a threat actor interested in specific Middle Eastern and Arabic-speaking countries. It also shows us an actor that puts effort in opsec by only using cloud providers. The malicious documents, the droppers and the RAT itself are developed around cloud providers. Additionally the attackers implemented anti-VM (and sandbox) and anti-analysis tricks to hide the malicious activities to the analyst. For example, the VM or the sandbox must have the keyboard layout of the targeted countries and a disk serial number. This campaign started in November 2019 and it is still ongoing. At this time, the API key is revoked and the Twitter account is suspended. However, the attacker can easily create new accounts and update the malicious files in order to still work. This campaign shows us that network-based detection is important but must be completed by system behaviour analysis.


Docx: 273aa20c4857d98cfa51ae52a1c21bf871c0f9cd0bf55d5e58caba5d1829846f

Template: 6cc0c11c754e1e82bca8572785c27a364a18b0822c07ad9aa2dc26b3817b8aa4


PE Autoit: b4a43b108989d1dde87e58f1fd6f81252ef6ae19d2a5e8cd76440135e0fd6366

PE Python: 4228a5719a75be2d6658758fc063bd07c1774b44c10b00b958434421616f1548







Coverage Additional ways our customers can detect and block this threat are listed below.

Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors.

Cisco Cloud Web Security (CWS) or Web Security Appliance (WSA) web scanning prevents access to malicious websites and detects malware used in these attacks.

Email Security can block malicious emails sent by threat actors as part of their campaign.

Network Security appliances such as Next-Generation Firewall (NGFW), Next-Generation Intrusion Prevention System (NGIPS), andMeraki MX can detect malicious activity associated with this threat.

AMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.

Umbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network.

Open Source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on