It is quite usual to have a license expiration date built into commercial software, but what about malware? Is it common for disabled malware to repair itself and resurface? Well, it’s definitely not common, but as you will see in this post, some cases do exist.
The sample we will look at belongs to the family of MBR ransomware which has been with us for more than a year now. Although these samples are obfuscated by various cryptors and kits, the behavior and the base code itself has not been modified much.
After execution, the sample decrypts itself, copies to %TEMP% folder usually as x2z8.exe, creates new child process which writes new MBR code to \\.\PhysicalDrive0 (overwrites current MBR code) and restarts the system.
Immediately after the restart, instead of starting your OS, the new MBR code displays some ransom text (usually in Russian or Ukrainian language) accusing you of holding pornography materials, using illegal software or violating other “laws”. You have to enter the correct password to get rid of this message and proceed with system startup. Of course, you won’t get this code for free…
Nothing new so far. Similar behavior can be seen quite often. However this particular family contains a feature that makes it more interesting. Each sample has fixed expiration date hardcoded limiting its lifetime. This date can be found not so far behind the altered MBR code.
At the very beginning of the new MBR code, there is a call to function which checks whether the sample has already expired or not. If the check succeeds then the sample behaves as you would expect from this kind of malware and displays the ransom message. However, if the check fails then execution jumps to the branch of code which does nothing more than heal itself by replacing its own infected MBR code with the clean one. It would behave in exactly the same way as if you had entered the correct password.
Have I already expired and should heal myself?
But why should malware even care about self healing? Isn’t this behavior against its nature? Well, as various malware builders/kits are being sold for money on black market these days, this is probably the way to force “customers” to periodically buy the latest versions.
The funny part about this story is the fact that we have also met variants with expiration date set to the quite far future (years 2033, 2082, 2171, etc.). We have even seen the builder (however quite old and rarely used) containing MBR code with series of NOP instructions in place of the original call to the date check function thus skipping this expiration test. These techniques are usually seen in cracks for commercial software.
Leave a reply