JAFF Ransomware via PDF attachment with Doc

We continuously receive phishing emails coming from a variety of sources, often containing attachments with malicious payloads. In this case the attachment was a bit more interesting because it embedded a .docm file inside a .pdf file.

The email that arrived to our servers had “Order” as subject, and no visible content, only a p(paragraph) HTML entity with an empty symbol, but fun was on the attachment.

Attack stages

The attachment was a proper PDF file that contained a .docm file embedded. Once you opened the pdf file de docm would unpack and execute its macros leading to the download of a file that, once repacked by the macro on execution, would be executed in the system.


More emails were received with the same subject, but with different files attached.
The files attached to these emails are pdf files with filenames probably related to the campaign and the day they were sent:

As we can see from the file names, they seem to follow the this rule:

Analysis of the PDF file

To do the analysis of the pdf file we use peepdf, and the first thing we can grasp from the information displayed is that is has JS code and probably an embedded file:

The document has two objects with Javascript content (object 4 and object 12) that allow the document to deliver its payload.
Detail of the Javascript code in object 4:

An array is defined in order to store the commands and parameters that will be executed once the document is loaded.
Detail of the JavaScript code in object 12:

This command executes the “exportDataObject“[1] that extracts the object referenced to an external file, that is “object 2”, and will be named “444AXGJNEOJ468.docm”.
We use this command extract embedded document with peepdf:

The stream dumped is compressed using gzip format, to deflate the file, prepend the gzip magic number and compression method before decompressing with gzip:


Analysis of the DOC file

It is common that malicious OLE documents include VBA Macros embedded inside the document like in this case:

The lines showing an M beside the ID of the OLE streams indicate that it contains VBA macro code that performs some actions other than simply defining attributes.
It has a complex code, not usual in this kind of files, that have few straightforward lines of code, most of the time obfuscated, just to download the executable file.
For further analysis we can extract the OLE streams containing VBA macro code from the doc file for that we will use olevba:

The code that we find sophisticated, in most cases macros are really straightforward, just a few lines of code (most of the time obfuscated) to download and execute the payload. In this case there are some internal subroutines and a post processing on the downloaded file that makes this code a bit more complicated. Here is a view of the object tree of the document:

By watching at the functions and procedures defined in the code we can have a first impression of what the script does when executed:

Another characteristic of this malware is the use of a User Form filled with different objects which properties will be used as variables in the execution of the script:

It is also remarkable the use of references to an object specifically used in LibreOffice, and that does not exist in word documents:

The extracted code is obfuscated using different techniques, but analyzing the code we can find the next stage of the infection that involves downloading a data file using HTTP from a determined domain. In this case an array of three different domains is used for resiliency matters:


Performing the same analysis over the rest of the files we obtained the following list of different domains:


Once executed the malware encrypts files with certain extensions and renames them ending in .wlu. You can also find this image below asking for the ransom payment in order to recover all your data.


[1] exportDataObject : Extracts the specified data object to an external file.


  • cName:The name of the data object to extract.
  • cDIPath(optional): A device-independent path to which to extract the data object. This path may be absolute or relative to the current document. If not specified, the user is prompted to specify a save location. Note: (Acrobat 6.0) The use of this parameter is no longer supported and should not be used. See the security notes above.
  • bAllowAuth(optional, Acrobat 6.0): If true, a dialog box is used to obtain user authorization. Authorization may be required if the data object was encrypted using the encryptForRecipients method. Authorization dialog boxes are allowed if bAllowAuth is true. The default value is false.
  • nLaunch(optional, Acrobat 6.0): nLaunch controls whether the file is launched, or opened, after it is saved. Launching may involve opening an external application if the file is not a PDF file. The values of nLaunch are:
    • If the value is 0, the file will not be launched after it is saved.(Default value)
    • If the value is 1, the file will be saved and then launched. Launching will prompt the user with a security alert warning if the file is not a PDF file. The user will be prompted for a save path.
    • If the value is 2, the file will be saved and then launched. Launching will prompt the user with a security alert warning if the file is not a PDF file. A temporary path is used, and the user will not be prompted for a save path. The temporary file that is created will be deleted by Acrobat upon application shutdown.