浏览器防护下的ActiveX问题

浏览器防护多使用ring3 API HOOK。下面结合网页防护类的主流产品分析其潜在的兼容性问题。

使用ring3 api hook实现的浏览器保护，不可避免的要遇到和文件监控一样的问题。在实际对抗中，网马不断发展升级，已经开始将浏览器中的ring3 hook摘除，为了对抗此类威胁，主流软件多会采取不断检测自己的hook是否存在，发现不存在则重新将函数挂钩。造成多款软件争抢一个API的现象，导致浏览器无响应或者响应缓慢。特别是与CreateProcesss相关的。

    在浏览器防护软件进行行为分析的时候，由于其他浏览器防护软件的参与会对浏览器的行为造成一定影响，这些影响可能是对堆栈的影响（由于多了一层Hook，实际调用的堆栈可能会增加一层）。以某浏览器防护软件为例，其堆栈检测只会向上追溯5层，如果同时共存3个软件，那么其想要检测的那层调用，则会由原来的第5层变为第7层，原来的检测方式就失效了。

    例如：360和金山网盾共存时，网马在创建进程时360进行检测。如果放行则会通过360的函数调用系统API，进而再次调用金山的进程创建检测，此时金山追溯堆栈会发现是360的模块调用，而不是js脚本解释引擎调用，予以放行。

    即使不考虑对堆栈的影响，由于不同浏览器防火软件都进行了拦截，对浏览器的行为也就产生了影响，造成相互的行为分析干扰，无法正确分析恶意行为，进而出现漏报或者误报的现象。

    例如：金山网盾在脚本解释层根据特征检出了恶意脚本，构筑在其上层的其他防护的行为分析就无法发现该恶意脚本的行为。

    再例如：360网盾会不断检测监控点是否存在，而检测的机制是基于二进制比较的，如果发现其他软件进行了HOOK，则用自己的进行替换，导致其他软件失效。