High Performance Network Security, Enterprise and Data-Center Firewall

High Performance Network Security, Enterprise and Data-Center Firewall

All your drives are belong to us

by RSS Patrick Yu  |  November 30, 2010  |  Category: Security Research

A new Ransomware module was recently discovered by Fortiguard Labs. When a machine infected with this Ransomware is restarted, the user is greeted with the following boot screen:

1Figure 1

The user would not be able to boot into their operating system unless they enter the right password. The website the user is instructed to visit is apparently still under active development, as French language support was just being added at the time of writing.

2Figure 2

The user is then instructed to type in the user ID provided to them in the boot screen. It appears that the ID is algorithmically generated as the server rejects invalid random IDs.

3Figure 3

And finally the user is brought to this page, which explains the situation and demands a ransom.

4Figure 4

The two payment methods accepted are PaysafeCard and UKash, which accept a few different currencies in various amounts, all roughly equivalent to USD $100.

5Figure 5

This particular variant (detected by Fortiguard AV as W32/Seftad.B!tr) was observed on a Vundo infection (detected by FortiGuard AV as W32/VB.CF!tr.bdr), and comes off the heels of recent GpCode activity. GpCode is ransomware that employs rigid encryption to corrupt documents on hard drives until they are decrypted ($120 USD). So far, RBNCrypter does not seem to be doing this - but it does use an aggressive attack method since it rewrites master boot record (MBR) code. By doing so, infected users cannot boot into their system (even through safe mode) - a rescue disk must be used.

MS Windows Boot code stored in the MBR is overwritten with RBNCrypter’s code which can be seen in Figures 1 and 7. The partition table is also wiped out (Figure 6), and the original MBR with preserved partition table is copied to offset +0x800h relative to the start of MBR (Figure 7).

BeforeAndAfterFigure 6

DataAndSavedBootFigure 7

During our tests, restoring the original MBR code and partition info from the saved offset (+0x800h) successfully restored the system, despite warnings that recovery methods would not work. Since the original partitions seem to be intact, various disk rescue utilities should be able to locate them, re-write the table and restore the MBR. We recommend trying the latter method, since manually writing the MBR can be potentially dangerous.

Special thanks to Fortiguard threat researchers Derek Manky, Doug McDonald and Guillaume Lovet for contributing to this story.

by RSS Patrick Yu  |  November 30, 2010  |  Category: Security Research
Tags:
comments powered by Disqus

FortiGuard Labs on the Web

search results hidden links