CLT was designed to test CIS 3.x not CIS 6.x with its integrated sandbox.
It can be run against CIS 6.x, but:
[ol]- It needs to be run extremely carefully. If you have not run it very carefully, it is likely to suggest vulnerabilities when none exist. With the BB off - you need to follow the guideline in this post adapting the instructions to CIS 6.0 as best you can. With the BB on follow the guideline in the same post again adapting the guidelines, except please leave the BB switched on. When running CLT click the ‘Sandbox’ button on the unlimited access alert.
- the results need to be interpreted very carefully, particularly if the sandbox or BB is on. Please make sure you check whether the exploit has actually managed to do what it may claim to have done. For example if it is supposed to open a browser page make sure that it has displayed something. If it is supposed to deposit and run a file make sure to check whether what it does has affected the main machine or just the sandbox.
- You probably also need to consider the impact of this more general post by Egemen: here[/ol]
Testing CIS 6.x’s COM control facilities
If you use CLT to test CIS’s COM control facilities please remember:
- To make sure you understand how these are supposed to work first. See this post here and note that CLT uses only in-process COM calls. You’ll need something else to look at asynch calls.
- CLT installer is an unrecgonised file, and it’s DLLs are likely therefore to be unrecognised. But there can be glitches, as you might imagine when you are receiving 1000 of files a day, CLT occasionally in the past has got registered as trusted because Comodo made it. This may happen again. Obviously you should be able to make the main executable or the .dlls trusted or untrusted by adding to the files list or altering some bytes in the file with a disk sector editor.