Development of the ‘CryptoApp’ ransomware finished; changes & active campaign

Not even a day ago I blogged on a piece of ransomware named ‘CryptoApp’ which I discovered while it was still in its development & testing phase: [Analysis of a piece of ransomware in development: the story of ‘CryptoApp’]. After publication I was contacted by another analyst who was able to link the information from my blog to other samples from an actual campaign. He matched both PDB paths as wel as behaviour to these samples, this blog describes the changed made to CryptoApp as well as the active campaign. A thank you to the researcher who contacted me sharing information, you know who you are.

I suggest reading my previous article on the discovery and full analysis of CryptoApp for the following to make any sense to you as its just a brief analysis and comparison.
You can read the article here: [Analysis of a piece of ransomware in development: the story of ‘CryptoApp’]

Analysis of the loader

The lure for this campaign originated from Western Union spam messages leading to a download of a payload from:


The file [transaction_certif_2412_installer.exe] has an interesting build date. (Again, this can be faked of course.) The date is the 12th of May, the same date as the original development version of CryptoApp was uploaded on
Development of the ‘CryptoApp’ ransomware finished; changes & active campaign
Inside the sample we find another interesting PDB path explaining its purpose (sort of):

D:projectsFinished – Downloader – edited by meCoreDownloaderReleaseCoreDownloader.pdb

The loader is written by the same guy(s) as the ransomware, both coding style and way of setting this up is the same. The loader works quite simple:

  • Setup an event and mutex both with the name ’coredownloader.mutex.02022015
  • Set the event and close handles to both
  • Create a new registry key called ’Downloader’ under ’SOFTWAREMicrosoftWindowsCurrentVersionRun’ and fill it with the current path of the downloader (most likely in case of interuption of the download)
  • Start a thread with code to download the payload
  • Download Thread – The payload download location is set to the result of calling [GetSystemDirectory()] which returns the system directory in my case ‘C:WindowsSystem32’
  • Download Thread – The filename to name the downloaded payload is set by using the [GetModuleFileName] function (in my case scrsss.exe)
  • After the download was successful it will remove the registry key added earlier
  • It will proceed by removing itself (the downloader) from disc using a bat script called ‘uninstall.bat’ which is written to disk. It simply tries to remove the original downloader, its content (in my case):

if exist “C:UsersBobbyAppDataLocalTemploader.exe” (
del “C:UsersBobbyAppDataLocalTemploader.exe”)
if exist “C:UsersBobbyAppDataLocalTemploader.exe” goto Repeat
del “C:UsersBobbyAppDataLocalTempconfig.ini”
del “uninstall.bat”;

  • After removing itself via the bat script it will proceed to execute the downloaded payload by calling [ShellExecuteEx()]

The payload was downloaded from either one of the following locations:

  • http://weddingclip[.]ru/media/csrsss[.]exe
  • http://61[.]219[.]82[.]98/tmp/csrsss[.]exe
  • http://petersauto[.]pl/media/csrsss[.]exe
  • http://stonewallphoenix[.]com/media/csrsss[.]exe
  • http://www[.]polistav[.]sk/media/csrsss[.]exe

Changes in CryptoApp

The initial sample that was being downloaded was still the same (old) CryptoApp; the one without the red lock screen. With this campaign however a related sample was also found with the hash f6884ad8c02372c660849e1ccea8dc19. This one contained some interesting changes from the first few samples (including the one from this campaign). Most notibly the lock screen placed on the infectee desktop background was modified and contains no mention of the Tor hidden service anymore. The message is also a bit more aggresive in a way:
The HTML file shown to the user has also been modified a bit, mentions of the Tor hidden service was removed as well while having some added red text at the top:
Besides these changes I didn’t find any major other changes. I confirmed the following items to still function the same as the older versions described in my previous detailed blog article:

  • Filetypes for encryption
  • Method of file encryption (including the file tag/marker of 0x2200AF)
  • File decryption
  • C2 communication protocol

The two things that changed together with the lock screens is the price. Current method of unlocking is by paying 2 instead of 1 Bitcoin. The Bitcoin address was also changed to 1HJdRLVffmFC5ooLAZHgAkXKvziisYDrqX. I checked this address and luckily and found that it has had 0 transactions till now; no money for the criminals.

Samples & IOCs

I’ve gathered the following unique samples:

  • Loader: MD5 – b379f16960b33740ac02d6fd58a1813c552620ce – [] [VT 32/56]
  • CryptoApp sample downloaded by the loader: MD5 – 677ec7f735be831256762920e1876443 – [] [VT 27/57]
  • Related CryptoApp sample (with changes): MD5 – f6884ad8c02372c660849e1ccea8dc19 – [] [VT 42/57]

The following domains and IPs were seen for the loader and CryptoApp itself:

  • (Seen from loader)
  • (Seen from loader)
  • (Seen from loader)
  • (Seen from loader)
  • (Seen from loader)
  • (Seen from CryptoApp)

By admin