South Korean Banks, Media Companies Targeted by Destructive Malware

A massive computer shutdown of two South Korean banks and media companies occurred Wednesday via an Internet malware attack. The malware wiped out the master boot records on the hard drives of the infected computers, overwriting the MBR with either one of these strings:

  • PRINCPES
  • PR!NCPES
  • HASTATI.

jarias-MBR

Figure 1: Snapshot of MBR after infection.

The attack also overwrote random parts of the file system with the same strings, rendering several files unrecoverable. So even if the MBR is recovered, the files on disk will be compromised too.

After that, the system is forced to reboot via the following command:

  • shutdown -r -t 0

That action causes the computers to be unable to start because the MBR is corrupted.

jarias-Corrupted MBR

Figure 2: Error message after reboot

Furthermore, before overwriting the MBR, the malware attempted to kill the main processes of two Korean antivirus products, Ahnlab and Hauri:

  • taskkill /F /IM pasvc.exe
  • taskkill /F /IM Clisvc.exe

The malware code does not contain any function related to network communication, and we don’t have any indication that it can communicate with a remote host.

Also, it didn’t make any other changes in the system such as dropping files or changing registry keys. The goal of the attack appears to be solely to make the targeted computers unusable.

A dropper was found that seems to be the original dropper for this attack. The 418KB file is UPX packed, with the following hash:

  • 9263E40D9823AECF9388B64DE34EAE54

This dropper dropped the MBR-killing module as AgentBase.exe in the %TEMP% folder, and started it.

It also dropped two clean files, Putty SSH client and Putty SCP client in %TEMP%. It then scanned the file system looking for the configuration files of two SSH clients:

  • Felix Deimel’s mRemote
    %sAppData\Local\Felix_Deimel\mRemote\confCons.xml
  • VanDyke’s Secure CRT
    %sAppData\Roaming\VanDyke\Config\Sessions

If the malware finds a configuration file, it looks for any entry for a “root” user on a remote system, extracts the connection information, and uses the Putty clients to check if access to the system is available:

  • %s -batch -P %s -l %s -pw %s %s %s:/tmp/cups
  • %s -batch -P %s -l %s -pw %s %s “chmod 755 /tmp/cups;/tmp/cups”

The malware then drops another file in %TEMP% named “pr1.tmp,” which is a BASH shell script that attempts to perform partition killing on three Unix types: Linux, HP-UX, and SunOS.

jarias-shellscript

Figure 3: Part of the shell script used in the Unix attack.

This script checks the system, and then calls a specific function for each OS in an attempt to overwrite the disk partitions. In case the operation cannot be executed, it also tries to delete the following folders:

  • /kernel/
  • /usr/
  • /etc/
  • /home/

McAfee Labs was able to identify the following hashes related to this attack:

Wiper module

  • DB4BBDC36A78A8807AD9B15A562515C4  ApcRunCmd.exe
  • F0E045210E3258DAD91D7B6B4D64E7F3  ApcRunCmd.exe
  • 0A8032CD6B4A710B1771A080FA09FB87  mb_join.exe
  • 5FCD6E1DACE6B0599429D913850F0364  OthDown.exe

Dropper

  • 9263E40D9823AECF9388B64DE34EAE54  APCRunCmd.DRP

Unix Shell Script

  • DC789DEE20087C5E1552804492B042CD  pr1.tmp

As we looked in our sample database for related files, we identified two other samples that have the same basic structure as the preceding samples, but they don’t have the MBR-killing capabilities:

  • E4F66C3CD27B97649976F6F0DAAD9032 E4F66C3CD27B97649976F6F0DAAD9032.bin
  • 50E03200C3A0BECBF33B3788DAC8CD46  jar_cache1221312510715123682.tmp

These samples were found in the wild in August and October 2012. They share the same basic stub for the MBR-killing malware, but they are simple downloaders and don’t have commands to kill antivirus processes. They have only MS-DOS commands to remove themselves after executing.

Based on our analysis, these samples are not related to the attack, but they may be the same malware stub used by the attackers to create the MBR-killing code, sort of a template Trojan that can be tweaked to execute any function.

It’s possible to see the differences in the payload on the following images:

jarias-old

Figure 4: Payload of old samples.

jarias-new

Figure 5: Payload of new samples.

As we can see, the commands executed are different but the data structure is the same.

McAfee detects the samples involved in the attack as KillMBR-FBIA and Dropper-FDH.

 

‘Bioskits’ Join Ranks of Stealth Malware

We have seen many discussions of the MyBios “Bioskit” discovered at the end of 2011. MyBios was the first malware to successfully infect the Award BIOS and survive the reboot. It was first discovered by a Chinese security company; many other security vendors published detailed analyses after that.

We have seen a lot of samples targeting the master boot record (MBR) to survive a reboot and reinfect a system. We found a sample in our collection that infected the MBR. Further investigation showed that the next variant of the malware was a Bioskit. The first variant of the malware was an executable that infected the MBR; the second was a DLL with the Bioskit component. We will discuss the second variant in this blog.

DLL Analysis

The malware’s main dropper is a DLL that is responsible for the MBR infection. It reads the original MBR from Sector 0 and writes it to Sector 15.

MyBios code writes the malicious MBR.

The malware overwrites the original MBR in sector 0 and writes the file to be dropped (the downloader) in hidden sectors. The DLL copies itself to the Recycle folder and deletes itself. The downloader is dropped and executed every time the system is started.

The malicious MBR

The next two screens show the malicious MBR code, which reads the original MBR from Sector 15 into memory at location 0000:7c00. Control passes to the original MBR at this location and the system boots in the normal way.

Usually the boot sector is read to this memory location in a clean system after the power-on self-test and INT 19 jumps to location 0000:7c00.

The malicious MBR at 7c00 before the interrupt

The original MBR at 7c00 after the interrupt

All the components dropped will be present in the DLL, including the utility cbrom.exe from the BIOS manufacturer, which the malware uses to flash the BIOS.

 

Dropped System File

The sys file responsible for flashing the BIOS is similar to the one seen in MyBios. Unlike bios.sys, the code to check the BIOS manufacturer and the BIOS size is present in the DriverEntry. However, the functionality of both the drivers remains the same.

Code to check for Award BIOS

The rest of the code responsible for backing up and flashing the BIOS is present in the driver dispatch. A graph showing the code flow of both MyBios and the Niwa rootkit can be seen below.

MyBios code flow

NIWA code flow

What’s interesting is that the strings observed in both malware are almost identical.

MyBios:
This is not an Aword BIOS!

NIWA:
This not an Aword BIOS!

Identical strings:
Flash Aword BIOS form disk c bios.bin success.
SMI_AutoErase Aword Bios Failed.
ExAllocatePool read file NonPagedPool failed.
Backup Aword BIOS to disk c bios.bin success.
MmMapIoSpace physics address:0x%x failed.

It cannot be a coincidence that almost all of the strings are identical (including misspellings and bad grammar). This suggests the same individual or group is behind both of these BIOS-flashing malware.

McAfee detection and cleaning

McAfee detects this infection as “Niwa!mem” and successfully cleans the MBR infection and deletes all other malicious dropped components.

Conclusion

We have now seen two Bioskit malware in the wild within a couple of months. When the first Bioskit was identified, we did not know how soon we would see another. Now it appears we should expect to see more in near future. It’s not hard to detect and clean the MBR, but cleaning BIOS infections will be a challenge for security vendors.

Backdoor.Tidserv and x64

On April 12, 2011, KB2506014 was released to address a vulnerability affecting Windows Vista and later operating systems running on the AMD64 platform. Malware was exploiting the vulnerability to load unsigned drivers and stay resident in kernel mode.

Backdoor.Tidserv (a.k.a. TDL4) is one such threat that is patching operating systems’ loader files on-the-fly in order to ensure that its advanced rootkit capabilities work. As may be expected, Tidserv attempted to work around the KB2506014 patch, as noted in the following code snippets taken from the ldr16 entry of the threat’s encrypted file system:


 
Here, the hooked int13 (the 16-bit disk operations interrupt) attempts to identify the moment when the operating system loader reads the kdcom.dll file from disk, then identifies which version it reads (either x86 or x64) and replaces it with the corresponding rootkit loaders ldr32 and ldr64.

Further down, just after the /MININT parameter patch, the code was updated to also patch the STATUS_INVALID_IMAGE_HASH (0xc0000428) error code that was returned from winload.exe to an invalid value (0xc428). This is meant to throw off the digital signature enforcement for kdcom.dll.


 
But, let’s see how that works in real life, as well as what it takes to actually get infected. For those purposes we collected the latest Tidserv samples (released on 2011-05-03) and set up a Windows 7 SP1 x64 computer with default settings running on it. Even from the start, the threat kindly asks the user (through the user account control (UAC)) to allow it to run as an administrator:


 
Who would say “Yes” to an unsigned installer? Hopefully, not too many of us; however, if the user clicks “No,” the threat retries and another UAC window is displayed in the hope it will convince the user that there is no other way to continue. It takes an average of about 16 “No” clicks in order to actually stop the threat from asking to run with administrative privileges and hence prevent it from installing.

Once installed, the threat immediately reboots the computer in order to load itself into kernel memory, since it can only bypass the digital signatures enforcement at boot time—or at least that’s what would be expected.

Even with the unknown error reported, the system loader detected the on-the-fly changes made by the rootkit loader and therefore started the System Repair mode. However, it will not touch the infected MBR, since it only expects that files were affected.


 
The process repeats itself at reboot, since the infected MBR loads once again, only this time the repair process fails:


 
While the hooks placed during the MBR infection take precedence over the operating system loader, in theory the hook code can, on-the-fly, patch any protection the OS loader might employ. But, it seems it’s not the case here and the threat should undergo more changes before being able to bypass the driver signing policy.

The good news is that the threat is effectively prevented from running. The bad news is that the system is rendered unusable.

This brings back memories of the DOS era, when there were no hardware protection mechanisms in place. This resulted in a “fair” battle between malicious code and antivirus products, usually leading to victory for the one that had the privilege of being the first to the post.

From this point of view, for the time being, malware still has a fair chance because even the most modern operating systems still need to start up from good-old 16-bit mode. However, there is an end to that privilege—namely, by enforcing the requirement that only signed code will boot through the BIOS.