A few weeks ago reports emerged about victims being attacked by a new ransomware variant called XRTN. What’s interesting in this case, is that XRTN uses a “pure” batch script as the actual payload that is responsible for filesystem encryption, presumably to bypass anti-virus (AV) solutions.
Until now, binary files were the mainstream method for payloads used by ransomware. Static signatures used by traditional AVs are a classic approach for detecting known threats. Scripts, meanwhile, contain text-based commands that both appear benign to AV tools, as well as are harder to create a reliable signature for. Arbitrary obfuscation of scripts further complicates things for an AV to generate effective signatures that do not introduce multiple false positives.
The XRTN campaign was seen in the wild in the form of spearphishing emails that contain an obfuscated Javascript file (SHA-1 d1af04abd78c357b04037cdf8e65162c3da654b0), which is executed on the attacked system by means of social engineering. Upon execution, this JS file downloads : a .docx MS Office document, the Gnu Privacy Guard (GPG), masqueraded as a CSS file, and a batch file that performs the encryption.
Fig. 1: JS function that downloads the requested payload
To the best of our knowledge this JS has not yet been used in active web pages, and requires that a user double click the attachment in order to execute.
Fig. 2: Download and execution of the batch file
The batch file (SHA-1 82f367733b8bad4800d1f526980574d46a43fff3) is the actual payload of the XRTN ransomware. It is a fairly simple obfuscated script (with apparent bugs) that uses a hard-coded public key to encrypt all files with pre-defined extensions (pdf, doc, docx, etc.) throughout the filesystem.
Fig. 3: Hardcoded public key used for encryption
In a very ransomware-fashion, the payload looks for common file extensions used for documents, graphic files, compressed files and even database files (e.g., .sqlite). It will then encrypt them with the above public key and add the extension .xrtn to the filename.
Another common ransomware technique is to attempt to delete any shadow copies on disk. This will typically result in a User Account Control (UAC) window that asks the user to approve the command, which if accepted eliminates the ability to use the System Restore function. The command is executed using a VBS file that is placed in the %temp% directory and later on deleted.
Fig. 4: Deleting Shadow Copies from disk
Once the encryption process is complete, the script will generate an HTA file, drop it to the %temp% location on disk, and add it to run automatically at startup by adding a registry key to
HKCUSOFTWAREMicrosoftWindowsCurrentVersionRun
The actual HTA filename is arbitrary. We detected multiple versions in the wild. The file contains the usual ransom message that instructs the machine’s user to contact an “expert” at [email protected] to decrypt the files.
Fig. 5: The ransom screen
XRTN demonstrates that you don’t need state-of-the-art technology to circumvent traditional AV defenses. This simple implementation method, of using a batch script for the actual payload, does the job. Fortunately, a robust behavioral analysis engine can detect script-based threats like XRTN.
Fig. 6: Partial view of the behavioral analysis output from the SentinelOne agent.
