Category Archives: Compromise Detection

DeXRAY 2.0 released

Posted on by

Recently I was contacted by two fellow DFIRers (thx @JamesHabben and @bmmaloney97) who suggested some improvements to the tool.

James mentioned to me a type of Quarantine files that I never heard of (Lumension LEMSS) and was kind enough to provide the recipe on how to handle them which I implemented in the tool (hope it works!).

Brian wrote some piece of code to integrate it with DeXRAY. Thanks to his efforts McAfee BUP files are now finally properly handled (the older version of DeXRAY required the user to carve out the decrypted malware, because DeXRAY didn’t handle OLE files). Thx!

In the effort to better parse some troublesome files I have added an additional routine to carve the files out (and I use it for Symantec ccSubSdk files).

Lo and behold the DeXRAY is now 2.0.

You can download it here.

The full list of supported or recognized file formats is listed below:

  • AhnLab (V3B)
  • ASquared (EQF)
  • Avast (Magic@0=’-chest- ‘)
  • Avira (QUA)
  • Baidu (QV)
  • BitDefender (BDQ)
  • CMC Antivirus (CMC)
  • Comodo <GUID> (not really; Quarantined files are not encrypted 🙂
  • ESafe (VIR)
  • ESET (NQF)
  • F-Prot (TMP) (Magic@0=’KSS’)
  • Kaspersky (KLQ)
  • Lavasoft AdAware (BDQ) /BitDefender files really/
  • Lumension LEMSS (lqf)
  • MalwareBytes Data files (DATA)
  • MalwareBytes Quarantine files (QUAR)
  • McAfee Quarantine files (BUP) /full support for OLE format/
  • Microsoft Forefront|Defender (Magic@0=0B AD|D3 45) – D3 45 C5 99 header handled
  • Panda <GUID> Zip files
  • Spybot – Search & Destroy 2 ‘recovery’
  • SUPERAntiSpyware (SDB)
  • Symantec ccSubSdk files: {GUID} files and submissions.idx
  • Symantec Quarantine Data files (QBD)
  • Symantec Quarantine files (VBN)
  • Symantec Quarantine Index files (QBI)
  • TrendMicro (Magic@0=A9 AC BD A7 which is a ‘VSBX’ string ^ 0xFF)
  • QuickHeal <hash> files
  • Vipre (<GUID>_ENC2)
  • Any binary file (using X-RAY scanning)

Beyond good ol’ Run key, Part 59

Posted on by

In my last post I talked about Bluetooth. I have a mixed luck testing anything related to this technology…

You see, there is that one more potential persistence mechanism associated with Bluetooth which I was unable to test successfully. Despite my efforts it didn’t work, but this is probably because I don’t have a proper set up. Perhaps people owning a laptop with the Windows 8 on it (and not Windows 8.1 or newer) could give it a go… It is another documented feature of Windows, so it should work.

So… there is a thing called ‘Bluetooth Software Radio Switch Function Prototypes’ described on the Microsoft page here.

Adding the entry

  • HKLM\SYSTEM\CurrentControlSet\Services\

BTHPORT\Parameters\Radio Support\

SupportDLL = Path to DLL

should allow vendors to register a DLL that will handle requests to Bluetooth radio to switch it on or off.

The Microsoft page provides a link to another page that is describing the sample source code demonstrating to programmers how to build your own supporting DLL. The funny thing is that the demo code uses a different key (BthServ instead of BTHPORT service) than the previous page, and a Unicode path instead of an ANSI path provided in the documentation. Searching for strings within c:\windows directory I could find references to BTHPORT\Parameters\Radio Support and not BthServ\Parameters\Radio Support so the documentation is probably okay, and the demo is not.

Well, in any case. It should work.