Saturday 3 June 2017

XData ransomware attacked users in Ukraine

On May 18, the author(s) of XData ransomware ran the massive attack against Ukrainian users supposedly leveraging the EternalBlue exploit as well as an ordinary spearphishing email delivery method. A week later, an anonymous user, supposedly the author of AES-NI ransomware the XData is based on, released the master private key. Currently, the XData decryption tools are available. We analysed the XData code and found two host-based 'kill-switches', one of them is about detecting an antivirus running on an infected machine.


XData is based on AES-NI ransomware code that was named that way because of using Intel® AES New Instructions.
Intel® AES NI - a new encryption instruction set that improves on the Advanced Encryption Standard (AES) algorithm and accelerates the encryption of data in the Intel® Xeon® processor family and the Intel® Core™ processor family.
On May 21st and 30th, the author of AES-NI ransomware released the master private keys and the AES-NI decoder. As stated in the BleepingComputer article, the AES-NI ransomware developer did not want to be responsible for the XData outbreak in Ukraine. He declared that the AES-NI source code was stolen and used in the XData attack.

The 'AES-NI' part of the code found in the XData cryptolocker:


Xdata ransomware is delivered through spear phishing emails as an email attachment or can be downloaded via a malicious link embedded in an email message. It was mentioned by Avast that XData also took advantage of the famous EternalBlue exploit that was used by the WannaCry ransomware.

The downloaded file is a dropper that installs and starts XData cryptolocker.


The dropper (MD5: c6a2fb56239614924e2ab3341b1fbba5) decrypts the cryptolocker (MD5: a0a7022caa8bd8761d6722fe3172c0af) using the hard coded AES 256-bit key.

To avoid being started multiple times on the same machine, the dropper creates and checks the following 'kill-switch' file using the GetFileAttributes() API call:
  • %Documents and Settings%\<USER>\Application Data\88e0ddf0-7b4d-40ef-b3a4-681a36f56107

If the 'kill-switch' file was not found, the dropper copies itself to %AplicationData% under one of the following names chosen randomly:
  • mssql.exe
  • mscomrpc.exe
  • mscom.exe
  • msdcom.exe
  • mssec.exe
  • mssecsvc.exe
  • msdns.exe
  • msaddc.exe
Another 'kill-switch' is about the presence of the following antivirus processes running in the system:
  • avp.exe
  • avpui.exe 
  • ekrn.exe      
  • egui.exe      
  • mfemmc.exe    
  • mfefire.exe   
  • mfevtps.exe   
  • pefservice.exe
  • mcsvhost.exe  
  • msascui.exe   
  • msmpeng.exe   
  • mpcmdrun.exe  
  • avshadow.exe  
  • avguard.exe   
  • avgnt.exe     
  • avastui.exe   
  • avastsvc.exe  
  • avgui.exe     
  • avgsvc.exe    
  • avguix.exe    

If the dropper finds an antivirus process running, it ends its execution without starting the cryptolocker. Otherwise, the dropper starts the XData cryptolocker process.

XData encrypts user's documents and other important files skipping '.exe' and '.dll' types and big ones (>10Gb).


The XData generates and saves the host RSA key pair in the '<UUID>.key' file, where '<UUID>' is constructed as '<COMPUTERNAME>#<HASH>',
The .key file content is encrypted using AES-256-ECB. Then, the AES-256 key is encrypted using the master RSA-2048 key and added to the end of the '.key' file. The master private key has been published on the BleepingComputer forum.

The user's files are encrypted in a similar manner. First, a file is mapped to the memory and the AES-256 is randomly generated using the CryptGenRandom() call for every file. Then, the content is encrypted using AES-256-ECB with no padding, which means, if the last block is less than 16 bytes, it is left as is.
After encryption is done, the file's AES-256 key is encrypted using the host RSA key and stored as the 264-byte block. The first 8 bytes of the block is the XData version signature 'A12AF21F97FFDE97 '.

AES-ECB 16-byte block encryption of the mapped file:

The encrypted file is renamed to get the '.~xdata~' extension.

Covering up traces

The cryptoocker creates and runs the '.cmd' file in '%TEMP%' folder to clean Event Logs and the Recycle Bin:
@echo off
timeout /T 10
FOR /F "tokens=1,2*" %%V IN ('bcdedit') DO SET adminTest=%%V
IF (%adminTest%)==(Access) goto noAdmin
for /F "tokens=*" %%G in ('wevtutil.exe el') DO (call :do_clear "%%G")
echo Event Logs have been cleared!
goto theEnd
echo clearing %1
wevtutil.exe cl %1
goto :eof
echo You must run this script as an Administrator!
rd /s /q %systemdrive%\$RECYCLE.BIN
del %0  


The cryptolocker leaves the '.txt' files in every folder with instructions to decrypt user's files.


The recent version of RakhniDecryptor by Kaspersky Lab was verified to successfully decrypt the files encrypted by the analysed XData sample.


  • Similarly to the WannaCry case, ransomware may use ShadowBrokers exploits to achieve a high proliferation rate.
  • Cryptoockers started using hardware acceleration for AES encryption like AES-NI.
  • Ransomware started detecting running antiviruses to prevent its cryptolocker code from being executed on a protected machine.
  • Similar to TeslaCrypt, the XData cryptolocker uses its own implementation (embedded source code) of crypto algorithms making impossible to trace CryptoAPI calls as well as simple call obfuscation. The only CryptoAPI function found was CryptGenRandom() used by XData to generate AES file keys.

No comments:

Post a Comment