Malware with Packer Deception Techniques

Malware with Packer Deception Techniques

As we’ve discussed on our blog several times, malware will make use of commercially available or “homebrewed” packers or cryptors to conceal its malicious code.

While there are many programs available used to scan packed programs, it’s simply not possible to detect everything, as new and advanced cryptor programs are regularly created by cybercriminals, many of which are sold in underground forums.

These programs, which are rarely seen in public domains, can create crypted programs that are almost never detected by conventional file scanners.

CRUM Cryptor, a privately developed and sold cryptor that was later cracked and leaked to the public domain.

However, you don’t need an advanced cryptor program to fool a file scanner. Sometimes, these programs can be fooled by making slight modifications to pre-existing packers. Observe the same file scanned across three different programs.

Exeinfo PE
PEiD
WSUnpacker

I went ahead and tried the automated unpacking feature with WSUnpacker, and it failed. This could indicate a false positive in the scanner.

Since there are three scanners that produce three results, we need to take a closer look at the file. First we’ll look at strings.

fsg_string

Near the beginning the “FSG!” fingerprint can be seen, but this is easily faked. We will need to look closer.

In some versions of FSG, there is a fixed entry point at offset 0x154. We can see that when looking at a normally packed FSG file.

normalFSGfile

The bytes at the entry point are usually the same with these packed files. 87 25 [skip 4] 61 94 etc…

normalFSG

If the original file in question is in fact FSG, it will likely follow a similar pattern. We can use a hex editor to verify this.

hexobserveFSG

The bytes are there, and they’re also at the same 0x154 offset. It seems like an FSG-packed file, but the entry point doesn’t seem to be where it should be. We now need to take things to the assembly level.

Start by debugging the program and step over the first few calls that perform runtime linking of library functions. Then, we end up on a call to VirtualProtect with a loop, which will change permissions of other memory segments, allowing them to execute code.

virtualprotect

The loop ends, and then another jump to the VA 0x400154. happens. You might notice the offset 0x154, signifying that this is the beginning of the FSG unpacker stub. Once inside, scroll down a few lines and set a breakpoint on a JMP instruction pointing to an offset to the EBX register. This takes you to the unpacked program, so essentially the start function loads the FSG stub.

jmptofsg

Once the program is dumped, some basic questions about its behavior can be revealed by looking at the strings, which don’t appear to be encrypted further. Below is a list of servers the malware will contact.

decodeStrings

While tools are always helpful when looking at malware, they’re not always going to provide accurate information to analysts. This is because malware simply doesn’t play by the rules that legitimate programs do, and is always changing to inhibit analysis and confuse analysts.

_________________________________________________________________ Joshua Cannell is a Malware Intelligence Analyst at Malwarebytes where he performs research and malware analysis. Twitter: @joshcannell

ABOUT THE AUTHOR

Joshua Cannell

Malware Intelligence Analyst

Gathers threat intelligence and reverse engineers malware like a boss.