You are browsing the archive for Forensic Analysis.

Decrypting MalwareBytes .quar files

November 8, 2015 in Forensic Analysis

A few years ago I developed script to decrypt .quar files created by MalwareBytes. Since the decryption routine was different from a typical xor I was not sure how the MalwareBytes will react – I asked them for a permission to release the code publicly for the benefit of the DFIR/RCE community, but unfortunately, they refused at that time.

Since I posted info about my script on one of the DFIR forums I have been asked many times by many researchers to share the script with them privately.

Today I noticed that the cat is out of the bag and the code for decrypting .quar files was already made public by someone else here.

The script is actually covering many other quarantine files as well which is awesome.

Great work by the Optiv guys.

Let’s hope that code for all types of Quarantine files will eventually be made public.


Since some people asked, here is a short perl script for decrypting .quar files:

use strict;
use warnings;
use Crypt::RC4;
use Digest::MD5 qw (md5 );

my $f=shift || die ("Gimme a file name!\n");
open F,"<$f";
binmode F;
read F,my $data,-s $f;
close F;

my $rc4 = Crypt::RC4->new( md5 ('XBXM8362QIXD9+637HCB02/VN0JF6Z3)cB9UFZMdF3I.*c.,c5SbO7)WNZ8CY1(XMUDb') );
my $newdata = $rc4->RC4( $data );

open F,">$f.out";
binmode F;
print F $newdata;
close F;

AntiEDR – Samples targeting EDR (Endpoint Detection and Response) solutions

November 7, 2015 in Anti-*, Anti-Forensics, Batch Analysis, Compromise Detection, Forensic Analysis, Incident Response, Malware Analysis

I have recently came across an non-intriguing intriguing sample belonging to a family of applications commonly known as a PUA/PUP (Potentially Unwanted Application/Program). The ‘intriguing’ part is that it is the first one I have ever came across that actively tries to detect an EDR solution installed on the system, and in this particular case – CarbonBlack.

The sample md5 is 1233411098A5EE69EB925C559B815510.

What caught my attention was a string ‘IsRunningCarbon’ that I came across when i was eyeballing some of the logs generated by my batch analysis script.

It was placed among many other interesting strings f.ex.:

  • IsTestingBox
  • IsVirtualMachine
  • HasVirtualDrive
  • IsRunningOnVMWare
  • IsRunningOnHyperV
  • IsRunningOnVBox
  • IsRunningOnXEN
  • IsRunningVPN
  • IsRunningIPSECLP2
  • IsRunningOpenVPN
  • IsRunningPPTP
  • IsRunningTools
  • IsRunningFiddler
  • IsRunningFiddlerCert
  • IsRunningDeepFreeze
  • IsRunningPacketCapture
  • IsRunningAVs
  • IsRunningESET
  • IsRunningVipre
  • IsRunningCarbon
  • IsFlashInstalled

so it looked like a part of a generic ‘sandbox/monitor/security product detection’ pack of routines.

When loaded into ILSPY, the code of the function referenced by the name turned out to be a simple ‘directory present’ check (if the ‘CarbonBlack’ directory exists in a predetermined location), but the message the existence of this routine in the code sends to the EDR vendors is that they start to be recognized.

carbonPerhaps it’s not a big deal, but certainly notable. Maybe it is time to introduce randomization in the way EDR-specific directories are named? Or hide them completely (rootkit)?

Of course, the detection of EDR was always possible, but since now it is being actively done I bet it’s just a matter of time when we will see first evasions…