Monday, August 27, 2012

System Updates

Let us know if you experience any issues with the site, we're in the final phase of a move to a fully cloud based storage service which should show some speed improvements as well as adding redundancy for sample and report storage.

We also have an alternate domain in the event of an outage

Thursday, August 12, 2010

Support for detecting ROR and ROL ciphers in documents

We added support for detecting executables ciphered with bitwise shift ciphers - ROR (shift right) and ROL (shift left) which was first reported from a sample from Mila's blog (contagiodump). Bitwise shifts are similar to multiple or division by 2's. This sample used a shift left of one position (rol 1) along with a 256byte XOR key.

Wednesday, July 28, 2010

CVE-2010-1297 Flash exploit variants

We haven't seen too many variations of the Flash exploit CVE-2010-1297, so we decided to take a look to see if there were a lot of samples using the proof on concept ones. Our tests showed some variation - 6 different embedded Flash files used in attacks:

Malware with pad.swf - Flash variant a (26810 bytes, 49ddb9b210e773b987b9a25678f65577):
306d7e608a52121aa4508e9901e4072e (AES 128b PDF Encryption)

Malware with kp.swf - Flash variant b (1297 bytes, ea24ea1063f49c594f160a57c268d034):

Malware with flate encoded Flash variant c (27181 bytes, 0ab61f2fe334e22b4defb18587ae019f; inflated Flash variant d 53345 bytes, ac69d954d9e334d089927a1bc875d13d):

Flash variant e (53902 bytes, 8286cc6dc7e2193740f6413b6fc55c7e):

Flash variant f (26774 bytes, bd7eac5ae665ab27346e52278f367635):

Flash variant g (26774 bytes, 4666a447105b483533b2bbd0ab316480):

Friday, July 23, 2010

XOR Key normalizing and hashing

Comparing XOR keys can be a bit of a pain, typically one would expect attackers to use the same shellcode to extract embedded executable code, giving the XOR key another similarity to compare when looking at different attacks.

One of the things we came up with early on is a key sum, simply counting the ascii values:

for ($i = 0; $i < strlen($key) - 1; $i+=2) {
$sum += hexdec($key[$i].$key[$i+1]);

This can be helpful with shorter keys, however given a 256 byte key counting up from 00 or down from FF can have the same key sum = 32640. This is where another solution is needed - a key hash. Keys can be found anywhere in a document, so hashing a key needs an extra step - normalizing the key. We decided to go with finding the highest values as the starting point - so the key would start with FF if present, if two or more FF appear, the next value is compared to get the highest multi-byte value. Once we have the normalized key, we take a simply md5:

Given this key:

When normalized becomes:

And the hash of the above is c9b69399459095f1b991eb1997a4d066.

Given this key:

Will be normalized to:

Normalize XOR key source code:

function normalizeKey($key) {
$values = hex2str($key).hex2str($key);
$size= strlen($values) / 2;
$high = chr(0x00);
$highest = '';
$highestLoc = 0;
for ($j = 0; $j < $size; $j++) {
for ($i = 0; $i < $size; $i++) {
if (strlen($highest) > 0) {
$check = substr($values,$i,strlen($highest));
//echo "Compare [".dechex(ord($highest))."] and [".dechex(ord($check))."]\n";
if ($highest == $check) {
//echo "Found partial [".dechex(ord($high))."]\n";
$pos = $i+strlen($highest);
if ($values[$pos] > $high) {
//echo strhex($highest)." ".strlen($highest)."\n";
$highestLoc = $i-1;
$high = $values[$pos];
//echo "found highest at $highestLoc [".strhex($highest).dechex(ord($high))."]\n";
} else {
if ($values[$i] > $high) {
$highestLoc = $i-1;
$high = $values[$i];
//echo "found highest at $highestLoc [".dechex(ord($high))."]\n";


$highest .= $high;
$high = chr(0x00);

$search = '';
for ($l = 0; $l < strlen($highest); $l++) {
$search .= "\x".dechex(ord($highest[$l]));

if (preg_match_all("/$search/s", $values, $matches, PREG_OFFSET_CAPTURE)) {
if (count($matches[0]) <= 2) {



$new = '';
for($i = $highestLoc+1; $i < $highestLoc+$size+1; $i++) {
$new .= $values[$i];

return strhex($new);

Now you can search on ViCheck for similar attacks by searching either the XOR Key sum, or key hash by clicking the "more" link on the report page on

Thursday, July 22, 2010

Email report enhancements

Hello, we're made a few changes to the emailed report to make things clearer:

Nuclear report.pps:
RESULT: Embedded executable detected.
Encryption level: 256 byte key.
Confidence ranking: 100 (18 hits).

External hash searches:
VIRUS SCAN VirusTotal: 11/42 (26%) detected malware
VIRUS SCAN Threat Expert: New

and a sample with just potential javascript but no embedded malware:

SCAN: Suspicious file - Javascript obfuscation syncAnnotScan to hide blocks
Confidence ranking: 75 (2 hits).

External hash searches:
VIRUS SCAN VirusTotal: 0/42 not detected
VIRUS SCAN Threat Expert: New

And lastly a sample executable file:
SCAN: skipped - see sandbox report - file format executable
Confidence ranking: 50 (1 hits).

External hash searches:
VIRUS SCAN VirusTotal: 11/41 (27%) detected malware
VIRUS SCAN Threat Expert: New

Wednesday, July 21, 2010

Report page enhancements

For recently processed documents such as PDF or MS Office (engine >=193) we are now highlighting more information about the embedded executable such as the encryption/cipher method and information about the key.

Example result:

Embedded Executable:

XOR encryption: Yes
Replacement cipher: No
Mathematical substitution cipher: No

Matching: full
Key Length: 256 bytes
Key Unique Sum: 32640 More
Key Location: @5888 bytes
Key Accuracy: 100.00%
Fuzzy Errors: 0
File XOR Offset: @0 bytes
XOR Key normalized hash: eb58ea3d9dfb335ddc5d064954bc0daf
XOR Key: 0x[d8d7d6d5d4d3d2d1d0cfcecdcccbcac9c8c7c6c5c4c3c2c1c0bfbebdbcbbbab9b8b7b6b5b4b3b2b1b0afaeadacabaaa9a8a7a6a5a4a3a2a1a09f9e9d9c9b9a999897969594939291908f8e8d8c8b8a898887868584838281807f7e7d7c7b7a797877767574737271706f6e6d6c6b6a696867666564636261605f5e5d5c5b5a595857565554535251504f4e4d4c4b4a494847464544434241403f3e3d3c3b3a393837363534333231302f2e2d2c2b2a292827262524232221201f1e1d1c1b1a191817161514131211100f0e0d0c0b0a09080706050403020100fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0dfdedddcdbdad9]

Tuesday, July 20, 2010


Thanks to Lenny Zeltser for including ViCheck on the Analyzing Malicious Documents Cheat Sheet.

It's probably a good time to introduce ourselves. ViCheck is a combination of cryptanalysis engine to detect encrypted executables embedded in documents, as well as multi-decoder for PDF to detect known exploits or Javascript obfuscation techniques. We also use a commercial sandbox to attempt to collect dynamic information from exploit documents, statically extracted and decrypted executables. We don't run our samples live on the internet, a honeynet captures requests for C2 domains internally.

Regarding our primary goal of detecting embedded executables in documents, we use an in house developed cryptanalysis engine to scan for and try leaked plaintext keys (a large amount of any executable file is zero-space which when encrypted with XOR algorithms leaks the key as plaintext), decrypt the executable and scan for imported libraries. We also detect mathematical substitutions and replacement ciphers, and combinations thereof.

Samples can be submitted via web form on from your local computer or a remote web url, or via email by forwarding suspicious emails to hereyougo at