Attack details
A new strain of ransomware has been discovered in-the-wild – and it features some unique tricks to keep itself below antivirus and security solutions. The infection chain most likely begins with an email containing a Windows Script File (WSF) attachment. We say “most likely” because no such email has surfaced yet – but as the WSF file exists, it’s likely just a matter of time before one does.Upon execution, the WSF file, which is basically Javascript code aimed for the wscript executable, it will download a file and perform various actions that will result in an infection of the SyncCrypt ransomware, which encrypts files whilst appending .KK extension to them.
Will download a file and perform various actions that will result in an infection of the SyncCrypt ransomware, which encrypts files while appending .KK extension to those encrypted files.
As it encrypts files, SyncCrypt will skip files located in the following folders:
windows\
program files (x86)\
program files\
programdata\
winnt\
\system volume information\
\desktop\readme\
\$recycle.bin\
When the encryption is finished, a new directory called README will appear on the desktop. This directory contains several files: AMMOUNT.txt, KEY, readme.html, and readme.png:
- The AMMOUNT.txt file is the ransom amount
- The key is the encrypted decryption key
- The other two files are the ransom notes.
SyncCrypt will then open and display the readme.html ransom note using the victim’s default browser, as shown below.
This ransom note contains instructions to send a payment, roughly around $500, to the specified bitcoin address. Once a payment has been made the victim is told to contact all of the following addresses: getmyfiles@keemail.me, getmyfiles@scryptmail.com, and getmyfiles@mail2tor.com. The message should contain the KEY file from the desktop directory in order to get the decryptor.
Evading AV’s like a BOSS
While WSF infections are common nowadays, this campaign includes some unique tricks that seek to outsmart traditional security solutions.
The file being downloaded is a JPG image. If opened by the user, they would see the following:
The image is not malicious by itself. But hidden within the image binary code are bits and pieces that, when assembled the right way, form an archive. This archive is extracted by the WSF script, into the newly created %Temp%\BackupClient directory, to reveal the following files:
It appears the image file contains the contents of readme.html and readme.png, the ransom notes in both image and html format, and sync.exe which is the actual ransomware payload.
Looking in the file’s binary, we can spot these interesting details:
Logic would suggest that if this data is being stored within that image file and is extracted, opening the file with archive manager such as 7zip, would reveal its secrets.. Right?
Watch what happens:
Somehow, the contents of sync.exe are missing – which means that any security solution that would unzip the image in order to analyze it would still have missed this attack.
So what’s the trick? How did they do it? The trick lies within the way the attackers stored the archive within the image file. Zip archives contain the magic-number of PKs in their first bytes. This helps identify the file as a zip archive for various programs and without them, the file appears corrupt. The archive within the JPG image indeed has the PK first-bytes within, but only before the readme notes. Which means that when we open the image with 7zip, it would only reveal these 2 notes, missing the payload. Clever!
When the WSF script analyses the file, it takes care of this issue before unzipping the archive and extracting it to that directory.
Let’s have a look at the WSF script to get a better understanding:
Notice vars u1, u2, u3: these are 3 different locations where the image is stored.
The script then tries to download each of those one after the other, if the first succeeds it will continue to process it(marked in green), if not it will move on to the second url and then the third. If all of them fail, it will quit.
The download is being done in a function called download, which defines an MXXML2.ServerXMLHTTP object and will GET the given url. If the response is OK, it will save that response to a predefined location.
The processing is being done in another function called exp, which looks like this:
The function will create a zip file and will write the PK bytes into it [producing the PK bytes from decoding (using another function called Base64Decode) a hardcoded string (UEsDBA==)].It will then read the downloaded file starting at specific location (s.position=86127) and append this data onto the newly created zip file. It will then make sure the file is a valid zip file, save it to the filesystem, and pass it to the unzip function to be extracted.
As stated already, this trick, however simple it may be, passes anti-virus solutions with ease. Since detection solutions try to detect known attacks, they are blind to everything new or innovative.When testing this image file with Votiro’s CDR solution, I got the image back in less than a second, fully intact and without its malicious attributes.
Fully visible, no loss of any kind, and…
Prevention, not detection
Votiro’s solutions stress detection over prevention. As a result, we don’t need to know beforehand what the attack will be in order to prevent it.
Votiro’s solutions examine each file, tearing it apart at the binary level and rebuild it using only the necessary attributes, leaving all non-relevant (possibly malicious) attributes behind.The whole process is faster than any solution product available today, and at a 100% success rate, who can do any better?