Category Archives: Compromise Detection

DeXRAY 1.6 – ccSubSdk files

Posted on by

Yesterday Brian Baskin pinged me on Twitter asking about ccSubSdk files that Symantec solutions store on the system in the following location:

  • C:\ProgramData\Norton\{0C55C096-0F1D-4F28-AAA2-85EF591126E7}\<product>\CmnClnt\ccSubSDK

f.ex.

  • C:\ProgramData\Norton\{0C55C096-0F1D-4F28-AAA2-85EF591126E7}\NIS_21.5.0.19\CmnClnt\ccSubSDK

The SEP may store similar files in different location:

  • C:\ProgramData\Symantec\Symantec Endpoint Protection\<SEP version>\Data\CmnClnt\ccSubSDK
  • C:\ProgramData\Symantec\Common Client\ccSubSDK
  • C:\Documents and Settings\All Users\Application Data\Symantec\Symantec Endpoint Protection\<SEP version>\Data\CmnClnt\ccSubSDK

DeXRAY didn’t support them and it triggered my interest. I pretty quickly identified the algorithm as Blowfish, but for some reason it didn’t work. Eventually, after struggling with it for a while I ended up understanding the issue: it was a problem of little vs. big endianess – unfortunately, the same algorithms can be implemented to work with different data -ness.

Once I figured it out, I added a basic support for both {GUID} files and the submissions.idx. Now, when I say ‘support’ I mean the decryption of the outer layer only and a basic interpretation of what I can deduct from the file structure inside submissions.idx. Once you look at the decrypted files you will realize that the files contain some sort of container to store a lot of information about the suspected files / network data and possibly other data sets sent to the AV Reputation engines + actual files. On top of that, in some instances the content of the files is not encrypted (with a second layer), and in some it is.

It’s quite a headache.

Still, it’s worth pursuing further as it seems to be a great forensic artifact that may help to identify a lot of file-system and network activities that may not be recorded anywhere else, or long forgotten. We can retrieve metadata and the content of long lost files. And since the reputation engine intercepts pretty much all unknown suspicious files, as well as some network artifacts a lucky forensic investigator may actually find a smoking gun there…

Here are a few examples:

  • A suspicious file (PE file can be retrieved)

pefile

  • Silent/heuristic AV detections

suspfile1

  • A download of a PE file (HTTP PE Download):
httppefile1
httppefile2

There are also file metadata submissions with forensically interesting bits in a form of XML-like report:

<Report 
 Type="File Vote Report" 
 Count="#NUM OF FILES#">
 <File 
  Index="#INDEX#" 
  Active_timestamp="#EPOCH#" 
  File_MD5="#MD5#" 
  File_SHA256="#SHA256#" 
  FileName="#FILENAME#" 
  Path="#PATH#" 
  Signature="#SIG#" 
  Issuer="#ISSUER#" 
  Version="#VERSION#" 
  File_Type="#FILETYPE#" 
  AVE_Blob="#AVEBLOB#"/>

The Epoch, file path, file name, and hashes can support investigation in many ways. I believe there is a lot to explore here + in similar files from other vendors (if such files exist).

If you have ccSubSdk files available and want to share them with me for research, I’d appreciate it.

Coming back to DeXRAY – 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/
  • MalwareBytes Data files (DATA)
  • MalwareBytes Quarantine files (QUAR)
  • McAfee Quarantine files (BUP)
  • 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 ‘VSBX’ string ^ 0xFF)
  • QuickHeal <hash> files
  • Vipre (<GUID>_ENC2)
  • Any binary file (using X-RAY scanning)

Thanks to Brian for raising the interesting challenge and patiently listening to my questions and comments 🙂

The latest version of DeXRAY can be found here.

Beyond good ol’ Run key, Part 45

Posted on by

RDP was a feature guest in the last two parts of the series. Time for the third visit as there is still something to write about…

Using dedicated addins one can change the behavior of RDP session by leveraging a mechanism that Microsoft calls Virtual Channels.

Quoting directly from the web site:

Virtual channels are software extensions that can be used to add functional enhancements to a Remote Desktop Services application. Examples of functional enhancements might include: support for special types of hardware, audio, or other additions to the core functionality provided by the Remote Desktop Services Remote Desktop Protocol (RDP). The RDP protocol provides multiplexed management of multiple virtual channels.

The mechanism is implemented using DLLs, and since it is a legitimate feature its implementation and persistence mechanism are very well documented on the web site.

While the web site describes the HKCU keys only:

  • HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default\Addins
  • HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\connection\Addins

the HKLM works as well (at least for the Default; I have not tested the connection ones cuz it’s Friday 🙂 ).

f.ex.:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Terminal Server Client\Default\Addins\Malware
    Name  = c:\test\test.dll

virtchan3

Unlike the ClxDllPath Path presented in part 44, the Addins DLLs are loaded not immediately after mstsc.exe is launched:

virtchan1

but only after the actual connection with the remote system is established:

virtchan2Note: If you want to test it, make sure that the DLL you want to load matches the mstsc.exe architecture (32- or 64-bit)