卡巴斯基ksn红而不杀，可能不是卡巴斯基cdn节点缓存更新不及时的问题

kaba777

一、测试信息
测试开始时间：2024年12月23日21:15 测试结束时间：2024年12月24日22:40
测试样本：QuarkPC.msi 来自https://bbs.kafan.cn/thread-2277419-1-1.html （感谢 #zhuzhu009 提供）
Opentip：https://opentip.kaspersky.com/be7ea121e425e39602282e2bbff7434064150d494cee2ba6c16f8107736e0736/results
（备注：截至发帖时opentip状态已发生变化，测试时opentip状态见附件）
测试环境：VMWare 17.6.2，宿主机&虚拟机Windows 10 企业版(正版) 22H2 build 19045.5247，联网（ip类型：isp，dns：自动，防火墙：宿主机卡巴斯基无修改），第三方软件：7zip 23.01 x64、VMWare Tools 12.4.5.23787635
测试在vmware虚拟机内进行，在虚拟机内使用火绒剑的系统模块监控卡巴斯基软件的网络连接，同时检查火绒剑的网络模块中avp.exe的所有网络连接、以及宿主机的卡巴斯基网络监控中vmnat.exe的所有网络连接，保证虚拟机中卡巴斯基软件的所有对外连接受到监控。由于目前掌握的卡巴斯基软件联网动作均由avp.exe执行，部分测试仅抓取了avp.exe的网络连接日志。
测试包含的动作包括：查看ksn信誉，右键扫描，双击。测试时通过重启虚拟机系统清除本地可能存在的ksn信誉缓存。为保证火绒剑正常运行，关闭卡巴斯基的开机启动和自我保护功能。

二、测试结果及分析
以下测试按时间排序，所有涉及的测试日志文件见附件。由于主要操作及监控均为实时响应，难以捕捉截图，此次测试以文字说明为主。测试中所有右键扫描结果均为miss（发帖前测试最新版卡巴斯基已可扫描杀或文件监控杀此样本）。由于卡巴斯基其他组件也可能产生网络连接，日志中记录的个别发生时间相近的事件可能无法准确判断，请自行分辨或另行测试。如无特别说明，时间均为2024年12月23日晚至2024年12月24日凌晨。
对日志中dns解析的说明：由于火绒剑导出日志不包含网络请求的完整数据，可通过以下方法分辨dns请求：所有对192.168.48.2:53的通信为dns请求；根据日志中data字段倒数第7位判断dns请求解析的域名，3（data字段以03 64 63 31结尾）为dc1.ksn.kaspersky-labs.com，6（data字段以06 64 63 31结尾）为dc1-st.ksn.kaspersky-labs.com，8（data字段以08 64 63 31结尾）为dc1-file.ksn.kaspersky-labs.com。

测试1：
测试开始时间：2024年12月23日21:15 测试结束时间：2024年12月23日21:20 日志记录：无
说明：测试1开始时卡巴斯基尚未识别该样本，ksn信誉显示未知，右键扫描、双击（约10秒内）卡巴斯基均无反应。为避免对后续测试产生影响，双击约10秒后回滚虚拟机快照至先前保存的无污染状态。根据opentip信息，卡巴斯基于21:32添加了对该样本的识别（虽然这3个识别在21:14就已经出现在opentip的动态分析结果中）。

测试2：
测试开始时间：2024年12月23日21:29 测试结束时间：2024年12月23日21:32 日志记录：avp.exe的网络行为，从第一步测试操作开始
操作节点：21:29:28 查看ksn信誉；21:30:03 右键扫描
日志：查看ksn信誉时卡巴斯基先请求dc1.ksn.kaspersky-labs.com，与返回的202.163.7.42通信，然后请求dc1-file.ksn.kaspersky-labs.com，与返回的4.1.82.186通信。此时ksn信誉显示未知。右键扫描时请求dc1.ksn.kaspersky-labs.com和dc1-file.ksn.kaspersky-labs.com，与返回的202.163.7.42和4.1.82.186通信，扫描到21:30:40:911（37秒）时请求dc1-st.ksn.kaspersky-labs.com，与返回的62.128.100.92通信。

测试3：
测试开始时间：2024年12月23日21:33 测试结束时间：2024年12月23日21:39 日志记录：avp.exe的网络行为，从第一步测试操作开始
操作节点：21:33:42 查看ksn信誉；21:34:08 右键扫描；21:35:48 右键扫描；21:38:26 右键扫描
日志：查看ksn信誉时卡巴斯基请求dc1-file.ksn.kaspersky-labs.com，与返回的4.1.82.186通信。此时ksn信誉显示不受信任（后续测试均显示不受信任）。右键扫描（第一次）时请求dc1.ksn.kaspersky-labs.com和dc1-file.ksn.kaspersky-labs.com，与返回的202.163.7.42和4.1.82.186通信，扫描到21:34:37:369（29秒）时请求dc1-st.ksn.kaspersky-labs.com，与返回的62.128.100.47通信。第二次、第三次右键扫描时和上述3个域名/ip通信，其中多次更换通信ip（见日志）。

测试4：
测试开始时间：2024年12月23日21:46 测试结束时间：2024年12月23日21:48 日志记录：avp.exe的网络行为，从第一步测试操作开始
说明：21:41:05更新病毒库至19时版本。
操作节点：21:46:23 查看ksn信誉；21:46:29 右键扫描；21:47:42 双击
日志：查看ksn信誉时卡巴斯基请求dc1-st.ksn.kaspersky-labs.com和dc1.ksn.kaspersky-labs.com，与返回的77.74.181.38和119.255.133.28通信。右键扫描时请求dc1-file.ksn.kaspersky-labs.com和dc1.ksn.kaspersky-labs.com，与返回的119.255.133.28和4.1.82.185通信，扫描到21:46:55:031（26秒）时请求dc1-st.ksn.kaspersky-labs.com，与返回的77.74.181.38通信。21:47:01:053（右键扫描32秒时）触发自动上传，请求dc1-file.ksn.kaspersky-labs.com，与返回的119.255.133.28持续通信。双击后请求dc1-file.ksn.kaspersky-labs.com和dc1.ksn.kaspersky-labs.com，与返回的119.255.133.28和4.1.82.185通信，21:47:43触发PDM:Trojan.Win32.Bazon.a终止进程，21:48:31删除样本。

测试5：
测试开始时间：2024年12月23日21:50 测试结束时间：2024年12月23日21:51 日志记录：avp.exe的网络行为，从上一次测试继续（未重启）
操作节点：21:50:39 右键扫描
日志：由于此次测试过程中，上一测试产生的持续上传产生大量通信，此次测试右键扫描时的请求和通信很难判断。21:50:49:124（右键扫描10秒、测试4右键扫描260秒）时avp.exe产生了2个意外的dns请求，与返回的62.67.238.152通信。

测试6：
测试开始时间：2024年12月23日21:53 测试结束时间：2024年12月23日21:55 日志记录：avp.exe的网络行为，从第一步测试操作开始
操作节点：21:53:54 右键扫描；21:55:04 双击
日志：21:54:13:683卡巴斯基意外的和80.239.170.176通信。右键扫描时卡巴斯基请求dc1.ksn.kaspersky-labs.com和dc1-st.ksn.kaspersky-labs.com，与返回的4.1.82.186和77.74.181.141通信。双击后请求dc1-file.ksn.kaspersky-labs.com和dc1.ksn.kaspersky-labs.com，与返回的202.163.7.91和4.1.82.186通信，21:55:07触发PDM:Trojan.Win32.Bazon.a终止进程，21:55:36删除样本。

测试7：
测试开始时间：2024年12月23日21:57 测试结束时间：2024年12月23日22:03 日志记录：所有网络行为，从手动启动卡巴斯基开始
操作节点：21:57:58 手动启动卡巴斯基；21:59:05 右键扫描；22:01:02 双击；22:01:42 右键扫描
日志：右键扫描（第一次）时卡巴斯基先请求dc1.ksn.kaspersky-labs.com，与返回的119.255.133.28通信，然后请求dc1-st.ksn.kaspersky-labs.com，与返回的77.74.181.34通信。双击时提示“Windows 无法访问指定设备、路径或文件。你可能没有适当的权限访问该项目。”并触发自动上传，请求dc1-file.ksn.kaspersky-labs.com，与返回的119.255.133.24持续通信。第二次右键扫描时无明显流量特征。

测试8：
测试开始时间：2024年12月23日22:05 测试结束时间：2024年12月23日22:09 日志记录：所有网络行为，从手动启动卡巴斯基开始
操作节点：22:05:28 手动启动卡巴斯基；22:05:38 文件反病毒监控发现样本；22:06:06 右键扫描；22:08:02 查看ksn信誉；22:08:36 右键扫描
日志：文件反病毒监控发现样本前意外的产生了4个dns请求，和77.74.178.23通信，请求dc1-st.ksn.kaspersky-labs.com，dc1-file.ksn.kaspersky-labs.com和dc1.ksn.kaspersky-labs.com，与返回的77.74.181.141，119.255.133.24和4.1.82.185通信。右键扫描（第一次）时卡巴斯基先请求dc1.ksn.kaspersky-labs.com，与返回的4.1.82.185通信，然后请求dc1-file.ksn.kaspersky-labs.com和dc1-st.ksn.kaspersky-labs.com，与返回的119.255.133.24和77.74.181.141通信。查看ksn信誉时卡巴斯基请求dc1-file.ksn.kaspersky-labs.com，与返回的119.255.133.24通信。

测试9：
测试开始时间：2024年12月23日22:13 测试结束时间：2024年12月23日22:16 日志记录：所有网络行为，从手动启动卡巴斯基（第二次）开始
操作节点：22:13:09 手动启动卡巴斯基；22:13:51 手动启动卡巴斯基；22:14:01 查看ksn信誉；22:14:24 右键扫描；22:15:33 双击
日志：查看ksn信誉时卡巴斯基请求dc1-file.ksn.kaspersky-labs.com，与返回的4.1.82.184通信。右键扫描时请求dc1-file.ksn.kaspersky-labs.com和dc1.ksn.kaspersky-labs.com，与返回的4.1.82.185和4.1.82.184通信，扫描到22:14:50:774（26秒）时请求dc1-st.ksn.kaspersky-labs.com，与返回的77.74.181.34通信。双击后请求dc1.ksn.kaspersky-labs.com，与返回的4.1.82.184通信，22:15:34触发PDM:Trojan.Win32.Bazon.a终止进程，22:16:02删除样本。

测试10：
测试开始时间：2024年12月23日22:23 测试结束时间：2024年12月23日22:27 日志记录：所有网络行为，从手动启动卡巴斯基开始
操作节点：22:23:47 手动启动卡巴斯基；22:24:33 查看ksn信誉；22:24:41 右键扫描；22:27:04 双击
日志：查看ksn信誉时卡巴斯基请求dc1-file.ksn.kaspersky-labs.com，与返回的119.255.133.24通信。右键扫描时先请求dc1.ksn.kaspersky-labs.com，与返回的4.1.82.186通信，然后请求dc1-file.ksn.kaspersky-labs.com和dc1-st.ksn.kaspersky-labs.com，与返回的119.255.133.24和62.128.100.49通信。双击后请求dc1.ksn.kaspersky-labs.com，与返回的4.1.82.186通信，22:27:05触发PDM:Trojan.Win32.Bazon.a终止进程，22:27:25删除样本。

测试11：
测试开始时间：2024年12月23日22:31 测试结束时间：2024年12月23日22:36 日志记录：所有网络行为，从手动启动卡巴斯基开始
说明：22:30:19更新病毒库至21时版本。
操作节点：22:31:51 手动启动卡巴斯基；22:33:03 查看ksn信誉；22:33:18 右键扫描；22:34:28 双击
日志：查看ksn信誉时卡巴斯基请求dc1-file.ksn.kaspersky-labs.com，与返回的4.1.82.186通信。右键扫描时先请求dc1.ksn.kaspersky-labs.com和dc1-file.ksn.kaspersky-labs.com，与返回的4.1.82.184和4.1.82.186通信，扫描到22:33:46:400（28秒）时请求dc1-st.ksn.kaspersky-labs.com，与返回的62.128.100.45通信。双击后请求dc1.ksn.kaspersky-labs.com，与返回的4.1.82.184通信，22:34:28触发PDM:Trojan.Win32.Bazon.a终止进程，22:35:04删除样本。

三、结论
通过以上测试可以初步推断，右键菜单中的查看在ksn中的信誉，对应的服务器为dc1-file.ksn.kaspersky-labs.com，双击时触发的PDM，对应的服务器为dc1.ksn.kaspersky-labs.com，卡巴斯基触发可疑文件自动上传，对应的服务器为dc1-file.ksn.kaspersky-labs.com。由于测试中卡巴斯基软件几乎所有的网络连接都能与dns请求对应，不难看出扫描时连接的服务器可能是dc1.ksn.kaspersky-labs.com或扫描一段时间后连接的dc1-st.ksn.kaspersky-labs.com（测试7中卡巴斯基软件在扫描过程中未与dc1-file.ksn.kaspersky-labs.com通信，可排除dc1-file.ksn.kaspersky-labs.com与扫描的关系），但dc1.ksn.kaspersky-labs.com作为双击时提供PDM的服务器，必定含有文件拉黑信息，个人认为卡巴斯基软件没有理由在收到文件拉黑信息后在扫描中忽略此信息（测试4、6、9、10、11），推断扫描时提供云服务的服务器应为dc1-st.ksn.kaspersky-labs.com。结合dc1-st.ksn.kaspersky-labs.com在dns解析上的差异（见附件），是否说明ksn对于某些不受信任的样本，通过扫描和运行时的云检查连接不同ksn服务器，实现扫描和运行使用不同灵敏度的策略（个人猜测也许是为新样本留出更多时间供人工分析）？另外，测试中发现双击触发PDM后再查看同一样本的ksn信息时，卡巴斯基软件会直接显示ksn信誉，并且不会和dc1-file.ksn.kaspersky-labs.com通信（测试8，由于不发生通信，日志中不体现），这是否说明dc1.ksn.kaspersky-labs.com和dc1-file.ksn.kaspersky-labs.com之间不只是功能不同，还具有不同的优先级？
此测试可能排除某些卡巴斯基cdn节点缓存更新不及时导致文件ksn不受信任但扫描不杀的可能性：上述测试已证明新加坡和北京的cdn节点不存在缓存更新不及时的问题（opentip状态不即时同步至ksn服务器为正常情况，非此贴讨论内容，见https://bbs.kafan.cn/forum.php?mod=redirect&goto=findpost&ptid=2277283&pid=55561794）；对于上述测试中涉及的3个域名，除dc1-st.ksn.kaspersky-labs.com不解析至202.163.7.x（新加坡）、4.1.82.x（新加坡）和119.255.133.x（北京）、dc1-st.ksn.kaspersky-labs.com和dc1-file.ksn.kaspersky-labs.com不解析至82.202.18x.x（瑞士苏黎世）外，剩余6个ip段（见附件）均同时作为dc1.ksn.kaspersky-labs.com、dc1-st.ksn.kaspersky-labs.com和dc1-file.ksn.kaspersky-labs.com的目标服务器使用，并且已发现有单个ip同时被用作3个域名指向的服务器。由于卡巴斯基的dns解析设置，东亚以外的卡巴斯基用户，默认不会连接到新加坡和北京的cdn节点，这也就意味着，对于所有非东亚地区的卡巴斯基用户，如果卡巴斯基的任意一个cdn节点存在缓存更新不及时而导致ksn失效的问题，可能会导致所有连接到此节点的卡巴斯基用户对最近被ksn不受信任的文件失去部分ksn功能，包括右键查看ksn信誉显示错误、以及双击ksn不受信任文件时不会触发PDM等，其中dc1-file.ksn.kaspersky-labs.com对应7个ip段（不包括新加坡和北京），也就是全球大概有七分之一的卡巴斯基用户会遇到ksn最近拉黑文件信誉显示错误的问题，而dc1.ksn.kaspersky-labs.com对应6个ip段（不包括瑞士苏黎世、新加坡和北京），也就是全球大概有六分之一的卡巴斯基用户会遇到双击ksn最近拉黑文件时不会触发PDM的问题。但是目前看来并不存在这样的问题。

附件：
1、整理后的日志
2、原始日志
3、测试时opentip状态：

4、对卡巴斯基3个域名dns解析的分析（2024年12月22日）：
附件.pdf (75.25 KB, 下载次数: 6)

2024-12-25 02:31 上传

点击文件名下载附件
2025年1月13日编辑

Wesly.Zhang

实际上，说它CDN缓存有点问题的原因是在 traces 里面，对于同一个 KSN 响应，SHA256-VERDICT 会返回不同的结果，我的怀疑理由是这个。

驭龙

感谢分享你的测试结果，我人气没恢复，稍后在加人气值

pal家族

前几天玩了下红警，觉得盟军超时空传送贼强，试了好几把，
无奈操作不给力，即使可以瞬移，还是没打赢。
所以我明白了个道理，很多问题的产生都在深层次，想解决就要深度分析，找到对策。想走捷径没用！还需要高层介入！

你们说呢？

版主手下留情！本人尊重论坛版规和国家规定，无意要违规，但是很多事情需要说明白才能推进有效的讨论，促进问题解决。

passionCN

感谢测试分享！

pal家族

Wesly.Zhang 发表于 2024-12-25 11:25
实际上，说它CDN缓存有点问题的原因是在 traces 里面，对于同一个 KSN 响应，SHA256-VERDICT 会返回不同的 ...

大佬，还有没有办法让官方处理这个问题呢。。。。

多变的风向

这个问题我早就遇到过了 ESET以前也出现过 不过很少 还出现过扫描好几次才杀

kaba777

Wesly.Zhang 发表于 2024-12-25 11:25
实际上，说它CDN缓存有点问题的原因是在 traces 里面，对于同一个 KSN 响应，SHA256-VERDICT 会返回不同的 ...

两张图显示的都是返回了两个报毒名，这种情况客户端至少能有反应吧，我发这个帖子主要想讨论的是，ksn不受信任但监控和扫描放行的情况。我看两张图中的两个报毒名vdcdanger值不一样，一个是high一个是none，我猜会不会是卡巴斯基设计如此，可能是有一些人工审核或者兼容性的考虑（会不会新版和21.3对这种返回值的处理有差别）？另外个人主观意见，我个人对ksn安全网络还是有一定的信心，我不是很相信卡巴斯基cdn会有缓存更新不及时的低级问题。（如果有那就是我错了。）

kaba666

感谢你的分析，但是作为用户，我无能为力！

ljp2

很有意思的问题，但是卡巴斯基网络CDN全球更新慢很正常吧