一个具有360有效签名的病毒样本，具体干什么的不知道

图钉鱼

写入内容且不影响数字签名有效，有3种常见的方法：
在一个已经签名的文件末尾直接追加任何数据（Overlay），会破坏签名！

1. PE文件（Windows可执行文件 .exe, .dll）的末尾证书表区域内附加数据，不会破坏签名，数字签名不校验证书表本身的内容。

2. 利用PKCS#7签名的“未认证属性”
这种方法更为复杂和罕见，它不是在文件末尾附加，而是在签名数据块内部做文章。
这种方法技术要求高，且能存储的数据量有限，远不如第一种方法灵活，因此在实践中很少被用于添加大块内容。
（PKCS#7 的未认证/未签名属性 unsignedAttrs）：这是在方法1的“证书表区域”之内、进一步深入到 PKCS#7 SignedData 结构内部，对 SignerInfo 的 unauthenticatedAttributes 字段植入数据（自定义 OID + 任意 OCTET STRING 等）。
区别：
方法2通常更“干净”：因为 unsignedAttrs 本来就允许存在（时间戳、复签名等也用它），额外 OID 往往不会让系统验签失败，许多验证器会忽略不认识的 unsignedAttrs。
方法1如果在 PKCS#7 之外胡乱加字节（额外 WIN_CERTIFICATE、非标准类型或大量填充），更容易被安全工具或深入解析器标记为异常，但对系统层面的签名有效性一般仍不受影响（因为整个证书表都被跳过哈希）。

两种方法都受同一硬约束：不能修改 Optional Header 中 Security Directory 的大小/偏移（那是被哈希覆盖的），否则签名必失效。因此“可藏数据的总容量”必须落在现有证书表 Size 范围内。
方法2受 PKCS#7/ASN.1 结构限制，容量相对更小；方法1在证书表范围内更灵活（能利用对齐、额外记录等），但仍不能突破该范围。
不能把数据追加到“证书表之后的文件末尾”来扩容，否则会进入哈希范围，签名会失效。
方法2：检查 PKCS#7 的 SignerInfo.unsignedAttrs 是否存在异常 OID、异常大的数据块、与时间戳/复签名无关的内容。
方法1：检查证书表总大小与实际可解析内容的差异、WIN_CERTIFICATE 记录数量/类型是否异常、记录间是否存在大块不可解析数据或异常填充。

它们不是同一个概念。方法2是方法1在更细粒度（PKCS#7 内部）的具体实现路径之一。两者共同点是：都利用了“证书表区域不参与 Authenticode 哈希”的特性来携带额外数据；不同点在于操作层级、可移植性、可检测性与可用容量。

3. 特定文件格式的特殊区域
某些复杂的文件格式可能定义了允许用户添加元数据的区域，而这些区域可能被设计为不影响文件签名。
MSI 安装包：与PE文件类似，MSI文件的签名也允许在文件末尾附加数据。
PDF 文件：PDF的签名机制更为复杂，支持“增量更新”。你可以在不破坏旧签名的前提下，向PDF追加内容并应用一个新的签名。但这与“在保持原签名有效的情况下修改”不完全相同，它更像是保留了一个可验证的历史版本。


资产的发现与准备
资产: 攻击者在2025年发现了一个于2015年编译并签名的合法文件：escsvc.exe。这个文件来自一个可信的供应商，其数字签名在Windows系统中被验证为有效。由于年代久远，该文件已不再被其原始开发者维护和更新。
关键特性: 攻击者通过逆向分析发现，escsvc.exe 内部包含一个文件处理模块（由sub_403250和sub_403540等函数构成）。这个模块的合法设计目的很可能是用于处理附加在程序末尾的配置文件、更新包或资源数据。这是一个在软件（尤其是安装包、自解压程序）中常见的设计模式？然而，这个模块存在一个致命的逻辑缺陷：
它被设计为读取并处理附加数据（Overlay）。
但它缺乏对这些数据的严格验证。它不会检查附加数据是否是预期的格式（如加密的配置），而是会根据某些指令或数据头，将其内容写入磁盘并尝试执行它。


攻击链条:
要理解这个攻击，首先必须理解Windows Authenticode数字签名的一个关键技术细节：签名并不覆盖文件的每一个字节。
1.  签名覆盖范围：当一个可执行文件（PE文件，如.exe）被签名时，签名算法会计算文件将被加载到内存部分的哈希值。这个范围由PE头中的SizeOfImage字段定义，它包括了PE头、所有节区（如.text代码节、.data数据节等）。
2.  签名“盲区”：
PE 的 Attribute Certificate Table（安全目录/证书表）这一整块区域。这里面可以包含一个或多个 WIN_CERTIFICATE 记录；最常见的是类型 0x0002（PKCS#7 SignedData）。你可以在“证书表区域”的任何未被哈希覆盖的字节里藏数据，比如：
在现有 WIN_CERTIFICATE 记录之后再放额外的记录；
在记录间/对齐填充里塞数据；
在某个记录内部（比如 PKCS#7 blob 的前后、结构外层）追加数据，只要仍属于证书表范围。

这部分数据完全不参与哈希计算，因此，对它的任何添加、修改或删除都不会影响原始数字签名的有效性。

它通过PE可选头中的数据目录表（Data Directory）来定位。
DataDirectory[IMAGE_DIRECTORY_ENTRY_SECURITY]这个条目包含了两个至关重要的信息：
VirtualAddress: 证书表在文件中的起始偏移地址。
Size: 证书表自身的总大小。



阶段一：攻击者的“考古”与发现

攻击者通过资产发现搜到了一个理想的“载体”——escsvc.exe。它具备所有完美载体的特征：
拥有有效签名：由一个可信的、知名的软件供应商在2015年签名。这意味着操作系统和安全软件在默认情况下会对其有较高的信任度。
年代久远且已废弃：程序不再更新，意味着不存在针对其漏洞的安全补丁，也更容易被安全分析人员忽略。
存在一个“可利用的合法功能”：这是最关键的一点。escsvc.exe内部包含一个文件处理模块（由sub_403250和sub_403540函数实现），该模块被设计用来读取并处理附加在自身文件末尾的数据（Overlay）。这在2015年当年可能是用于加载配置文件或更新包的合法功能，但在2025年，它成了一个可以被滥用的逻辑漏洞。


阶段二：武器化——“寄生”于签名之下的恶意代码

1.  “寄生体”：攻击者制作了恶意的HTA文件，其中内嵌了VBScript，这是攻击的第二阶段载荷。
2.  进行“寄生”操作：攻击者将这个HTA文件作为一个完整的数据块，直接附加到了escsvc.exe文件的末尾，起始偏移地址为0x21000。

此时，一个“武器化”的文件诞生了。它的结构如下：

```
[------------------------------------------------]
| escsvc.exe - 原始、未修改的PE结构 (2015年) |
| (PE Header, .text, .data, etc.)                         |
|                                                                       |
| [数字签名块 - Security Directory]                  |
|------------------------------------------------| <-- 数字签名哈希计算到此为止
|                                                                      |
| 恶意HTA文件内容 (2025年附加)                    |
| (从偏移地址 0x21000 开始)                           |
|                                                                     |
[-----------------------------------------------]
```

阶段三：执行与欺骗——利用签名建立的“信任链”

这是整个攻击中最关键的环节，它详细展示了签名是如何被利用的：

1.  第一层欺骗：操作系统验证
    当用户或系统尝试运行这个被修改过的escsvc.exe时，Windows加载器首先会检查其数字签名。
    加载器计算文件从开头到签名块之前的所有部分的哈希值。由于这部分完全没有被修改，计算出的哈希值与签名中解密出来的原始哈希值完全一致。
   结果：签名验证通过！Windows认为这是一个来自可信供应商的、未被篡改的合法程序。它会为其创建一个进程，并赋予其应有的信任级别。

2.  第二层欺骗：程序“合法”地执行恶意准备工作:

1. 初始执行与 decoy 操作
escsvc.exe 被执行。
escsvc.exe被设计成一个具有两种截然不同行为模式的程序。它在启动时会立即解析命令行参数，根据参数的有无来决定是执行良性的或者用于伪装的“A路径”，还是执行提取并执行恶意载荷的“B路径”。

阶段一：初始执行与路径选择
escsvc.exe被执行。

路径决策点: 程序进入WinMain (0x408cb2)后，其首要任务之一就是检查是否存在特定的命令行参数，如/func=或/sendmsg=。

路径 A - 正常路径
触发条件: 命令行中存在/func=或/sendmsg=参数。
执行流程:
a. 程序进入处理这些参数的良性逻辑分支。
b. 如WinMain反编译代码所示，它会调用GetModuleFileNameW和PathCombineW来构造指向同目录下其他工具（如shell\360ShellScan.exe）的路径。
c. 调用sub_408AB5 (ShellExecuteExW封装)来执行这些外部合法.exe文件。

路径 B - 被利用路径
触发条件: 命令行中不存在/func=或/sendmsg=等预设的 decoy 参数。这包括最常见的执行方式：用户直接双击文件。
执行流程:
a. 由于没有匹配到 decoy 参数，程序的控制流会绕过良性分支。
b. 程序接着会调用其内部的文件处理模块（由sub_403250和sub_403540等函数实现），进入阶段二。

阶段二：HTA载荷提取与释放
程序进入“核心恶意路径”。

a. 文件处理模块调用CreateFileW，传入通过GetModuleFileNameW获取的自身文件路径，获得一个对escsvc.exe本身的文件句柄hFile。
b. 调用SetFilePointerEx，将文件句柄hFile的指针移动到硬编码的偏移地址 0x21000。这是附加数据文件开始的地方。
c. 调用ReadFile，从当前文件指针位置（0x21000）开始，一次性或分块地读取直至文件末尾的所有数据。这部分数据包含HTA文件内容，它被暂存入一个内存缓冲区。
d. 调用WriteFile，将内存缓冲区中的HTA内容完整地写入磁盘上的一个临时文件。



阶段三：代{过}{滤}理执行与信任链滥用
HTA文件成功写入磁盘。

a. escsvc.exe（这个拥有有效签名的“白”程序）调用sub_408AB5 (ShellExecuteExW封装)函数。
b. 它请求执行的命令是：mshta.exe "C:\Users\[Username]\AppData\Local\Temp\radB74A3.hta"。
c. 此刻一个受信任的、签了名的进程(escsvc.exe)，请求另一个受信任的、系统自带签名进程(mshta.exe)，打开看似普通数据文件(.hta)。这个操作链在行为上非常“合法”，极难被传统的安全策略拦截。escsvc.exe成功地将执行恶意代码的责任“代{过}{滤}理”给了mshta.exe。

阶段四：内嵌VBScript执行与最终载荷
mshta.exe成功加载并解析了临时的HTA文件。

a. mshta.exe引擎开始执行位于<script language="VBScript">标签内的恶意VBScript代码。
b. 脚本首先执行window.resizeTo和window.moveTo，将HTA窗口变得不可见，实现无痕运行。
c. 脚本在C:\escsvc目录下释放toolsps.exe和加密的PowerShell脚本2.txt。
d. 通过WMI检查系统开机时间，如果小于3分钟认定为沙箱虚拟机，则执行异常的、重复的启动流程来对抗自动化分析。
e. 在正常环境下，脚本通过shell.Run执行toolsps.exe，并将一个长字符串形式的PowerShell解密命令作为参数传入，最终在内存中解密并执行2.txt的内容（主体）。
f. VBScript调用self.close，关闭HTA应用，完成其历史使命。


所有文件处理函数均通过GetFileSizeEx获取整个文件的大小（包括附加数据区），而非仅PE镜像大小：
sub_403250（0x403250）第28行：GetFileSizeEx(*a1, lpFileSize)
sub_403540（0x403540）第30行：FileSize = GetFileSizeEx(*a1, lpFileSize)
这意味着样本明确知晓“文件大小 > PE镜像大小”，并意图处理超出部分（附加数据区）。这不是BUG，是预先设置的逻辑。



二、样本跳转到附加数据区执行的具体实现
综合以上分析，样本跳转到附加数据区执行的流程可总结为：
通过GetFileSizeEx获取包括附加数据的完整文件大小。
通过SetFilePointerEx将文件指针移动至PE镜像之后的附加数据区。
通过ReadFile将附加数据读取至缓冲区。
通过VirtualAlloc分配具有PAGE_EXECUTE_READWRITE权限的内存。
将缓冲区中的附加数据复制至可执行内存，通过函数指针或CreateRemoteThread触发执行。


3.  第三层欺骗：代{过}{滤}理执行——“借刀杀人”
    在完成文件释放后，escsvc.exe进程调用ShellExecuteExW（通过sub_408AB5函数），请求操作系统使用mshta.exe来打开刚刚释放的.hta文件。
   这是欺骗链的顶点：对于任何行为监控系统（如EDR）来说，这个事件看起来是：一个拥有有效签名的、受信任的进程 (escsvc.exe)，执行了一个合法的、看似无害的操作——创建了一个临时文件，并请求另一个受信任的Windows系统自带程序 (mshta.exe) 去打开它。
    escsvc.exe成功地将执行恶意代码的“责任”转移给了系统自带的mshta.exe，自己则像一个无辜的中间人。对于安全软件来说，这个行为的发起者是一个“受信任的”已签名且是可信厂商的程序。

阶段四：攻击载荷激活
从这里开始，攻击链的后续部分已经成功地在系统和安全软件的“信任”掩护下启动：
1.  mshta.exe执行HTA文件中的VBScript。
2.  VBScript释放并执行toolsps.exe。
3.  toolsps.exe在内存中解密并执行最终的PowerShell载荷。
它在C:\盘创建escsvc文件夹。
它将两个硬编码的Base64字符串解码并写入文件：
base64Data32 -> C:\escsvc\toolsps.exe (一个执行器)
base64Data64 -> C:\escsvc\2.txt (一个AES加密的PowerShell脚本)

反沙箱检测:
脚本通过WMI查询系统开机时间。如果时间小于180秒，它会进入一个异常的、多次重复执行并自我终止的逻辑，旨在迷惑和干扰自动化沙箱分析。
内存中的最终载荷执行:
在正常环境（开机时间>180秒）下，VBScript通过shell.Run执行toolsps.exe。
同时，它将一个长字符串形式的PowerShell命令作为参数传递给toolsps.exe。
这个PowerShell命令在内存中执行以下操作：
a. 使用硬编码的密码(Admin111...)和盐(Salt1234567890123)生成AES密钥。
b. 读取C:\escsvc\2.txt的内容。
c. 在内存中解密2.txt，得到最终的PowerShell恶意脚本。
d. 使用Invoke-Expression在内存中直接执行解密后的脚本，不留下任何文件痕迹。

VBScript执行完shell.Run后，调用self.close关闭HTA应用，清理自身。



总结：攻击者利用有效数字签名的核心在于利用其覆盖范围的局限性，并将其与目标程序一个“可滥用的合法功能”（自读取附加数据）相结合。他们将一个2015年的可信程序，变成了一个“可信”的“木马”加载器，整个过程没有破坏签名，而是巧妙地利用数字证书的校验规则缺陷“合法”绕过了它，并利用签名建立的信任链来掩护其恶意载荷的释放和执行。

以下软件类别广泛使用这种模式：
软件安装包 (Installers): 这是最典型的例子。像 NSIS和 Inno Setup 这样的安装包制作工具，它们生成的可执行文件（setup.exe）就是一个小型的、签了名的“存根”程序。这个存根的唯一工作就是读取附加在自身末尾的、经过压缩的安装脚本和应用程序文件，然后执行安装逻辑。
自解压压缩包: WinRAR、7-Zip等工具可以创建自解压文件。这些.exe文件同样是一个签了名的解压存根，后面附加了整个压缩包的数据。运行时，它会读取自身的Overlay并解压。
软件更新程序/补丁 : 很多软件的更新程序是一个独立的.exe，它可能包含了需要更新的二进制补丁数据，这些数据就附加在文件末尾。
一些打包器和保护器: 某些软件保护工具会将原始代码加密或压缩，并将其作为Overlay附加到一个解包存根后面。
任何属于上述类别的、拥有有效签名的旧程序，如果其存根逻辑不够健壮（例如:没有对附加数据进行完整性校验），都可以被攻击者拿来，替换掉原始的附加数据，换成恶意的Payload。因此，仅在这一类别中，就有成千上万的潜在“载体”程序。

Rukia

似乎直接提交文件(衍生物及原文件的),bitdefender和symantec 都说文件是没有恶意.......


原文件sogou_pinyin_16c.exe, 收集了系统日志，倒是被Bitdefender添加检测了。

sogou_pinyin_16c.exe    QD:Trojan.Astraea.4223410237

图钉鱼

Rukia 发表于 2025-9-9 09:59
似乎直接提交文件(衍生物及原文件的),bitdefender和symantec 都说文件是没有恶意.......

BD和赛门铁克是机器分析的吧，360签名的东西这个样本有没有被加塞东西，360最清楚了，看楼上360直接kill。

图钉鱼

BD更新检测了：Application.HackTool.BIR（风险程序/工具）

发现这样本有个特征：
escsvc.exe  PE报头CheckSum字段值：0x23B89，但实际计算后的是值 ：0x8D534。



但是不能作为强特征使用，因为数字签名不校验CheckSum字段数据！
攻击者如刷新CheckSum值则特征无效，我实测更新CheckSum值后数字签名依旧有效。








“利用有效签名挂载恶意数据”的样本，常见现象之一是：PE 可选头的 CheckSum 字段与按规范实际重算的值不匹配。
但这一现象并非强特征，单凭此不能判定恶意，因为 Windows 对用户态映像通常忽略该校验和，且正常的签名流程、重打包或工具链差异也会导致不匹配。

PE 声称的 CheckSum（Optional Header.CheckSum 字段）：0x0023B89（十进制 146345）
重新计算的实际 CheckSum：0x008D534（十进制 578868） 不匹配的原因是后续对文件内容的非法更改（调整证书表）未同步更新 CheckSum。
关于“签名盲区”与验证要点：
Authenticode 在计算哈希时会排除两处数据：
Optional Header 中的 CheckSum 字段 4 字节；
Attribute Certificate Table（即安全目录/证书表，DataDirectory[IMAGE_DIRECTORY_ENTRY_SECURITY] 指向的整个区域）。
哈希的实际步骤等价于：
从文件开始哈希到 CheckSum 之前；
跳过 CheckSum 4 字节；
从 CheckSum 之后哈希到证书表开始；
跳过整个证书表区域；
从证书表末尾哈希到文件末尾。
因此：
只有当修改严格限制在上述“被排除的区域”内时，数字签名才仍可能保持有效。
修改 CheckSum 字段不会破坏签名，因为该字段被排除在哈希之外。攻击者完全可以在不破坏签名的前提下更新 CheckSum。
若在证书表之外（例如节数据、节间空隙、Overlay 等）改动任意字节，都会导致签名失效；若在签名后再向文件末尾（证书表之后）追加数据，也会破坏签名，因为该追加数据会被纳入哈希。
关于 PE CheckSum 的计算：

PE CheckSum 的算法是对文件内容进行 16 位加和并加上文件长度的校验。计算时会把可选头中的 CheckSum 字段视为 0（或等效地先减去其当前值），以获得稳定结果。
Windows 加载用户态映像通常不会强制核验该校验和，仅部分场景（如某些驱动或系统组件）才有要求。

不要将“签名有效 + CheckSum 不匹配”作为恶意的强特征；它只能作为弱特征，与证书表结构异常、WIN_CERTIFICATE 项可解析性、证书链与时间戳、文件内容与目录一致性、行为学证据等结合判断。
对“签名盲区”的重点排查应放在证书表内部是否藏有非 PKCS#7 的额外数据、证书表大小是否畸大、是否存在额外 WIN_CERTIFICATE 项以及样本是否在运行时主动读取证书表区域并执行所获数据。

1.修改一个被数字签名算法排除的 CheckSum 字段，会破坏签名吗？
不会。CheckSum 字段不参与 Authenticode 哈希，修改它不会改变签名验证的哈希结果。

2.PE 校验和的计算是否会把 CheckSum 字段自身算进去？
不会。计算时将该字段视为 0（或等价处理），以避免自指依赖。

上文部分内容有误，如在文件尾部附加数据会破坏签名，已修订。该样本是特化定制样本，高度特化处理。附带刚编译的小工具，校验更新PE校验和工具。

Lolo期待

卡巴斯基扫描miss，KSN白名单

菜叶片

ANY.LNK 发表于 2025-9-8 00:21
@wowocock 奇怪的东西，这是360的官方文件吗？

VT认为签名无效，微软上报系统信任这个签名（文件默认为c ...

大佬 这个好像不是反调试 是MSVC编译器初始化时的合法函数
该函数被__scrt_initialize_onexit_tables调用

以下是我的程序反汇编结果和你那部分反编译的伪代码高度相似 应该是的

lingchenheiye

图钉鱼 发表于 2025-9-9 03:33
写入内容且不影响数字签名有效，有3种常见的方法：
在一个已经签名的文件末尾直接追加任何数据（Overlay） ...

求教，这是什么软件的界面

swizzer

没有深究过，但是mshta似乎会直接识别文件中的strings然后执行？之前遇到过一个在mp3里嵌入恶意js的，mp3文件节完全正常，也能正常播放，但是mshta执行就会有下载行为。

有空了研究下

图钉鱼

lingchenheiye 发表于 2025-9-10 19:34
求教，这是什么软件的界面

DIE 查壳软件，现在扩展了很多功能

ANY.LNK

菜叶片 发表于 2025-9-10 10:57
大佬 这个好像不是反调试 是MSVC编译器初始化时的合法函数
该函数被__scrt_initialize_onexit_tables调 ...

简单看了下，IsDebuggerPresent的判断并不影响后续的执行逻辑，这里应该确实不是反调试的