求职招聘诈骗防骗指南：警惕“试岗、培训、内部沟通”诱导安装陌生 App

本文来自一次真实求职经历及后续安全分析。写下这篇文章，是希望正在找工作的朋友，尤其是应届生、转行者以及急于求职的人，在遇到类似套路时能多停一分钟、多核实一步。

最重要的一句话：正常招聘可以要求你面试、提交简历、参加合理的笔试，但如果对方在正式入职前强制要求你通过陌生链接安装 APK、企业签名 App、描述文件或所谓“内部聊天/试岗/培训软件”，请立即提高警惕。

一、事情是怎么开始的

最近我连续遇到了两起非常相似的招聘接触。

对方先通过邮件联系，询问我的求职意向和期望工作区域。从信息匹配程度来看，对方很可能利用了招聘网站上公开或半公开的求职信息。

这类接触最容易让求职者放松警惕，因为对方往往并不是随便编一个公司，而是会利用真实存在的公司名称、历史招聘信息，甚至寻找“曾经招聘过、现在已经停止招聘”的岗位包装招聘活动。

之后的话术会逐渐转向：

先进行线上沟通；
安排“试岗”“线上培训”“项目了解”或“内部面试”；
询问手机是 Android 还是 iOS；
要求安装所谓公司内部的招聘、聊天、办公或培训 App；
App 无法在常见官方应用商店正常搜索到，而是通过邮件、聊天消息或陌生网页发送下载链接；
以“不安装就无法继续面试/试岗”为理由催促求职者安装。

我遇到的其中一个 App 名为“聘聊”。由于安装方式和使用场景都非常反常，我没有直接安装到真实手机，而是在一个全新的 MuMu Android 模拟器中进行了隔离测试，并对 APK 和网络行为进行了进一步分析。

结果证明，这份警惕非常有必要。

二、为什么这种骗局特别容易成功

求职诈骗利用的往往不是某一个技术漏洞，而是人的心理状态。

找工作时，人很容易处于这样的状态：

已经投递很多简历，希望尽快得到回应；
收到“HR 主动联系”会产生机会难得的感觉；
担心自己质疑太多会失去岗位；
对方掌握自己的姓名、岗位方向、工作城市等信息，因此显得“很真实”；
“先试岗”“先培训”“下载公司内部软件”听起来似乎都有合理解释；
对 APK、企业签名、证书、手机权限等安全概念不了解。

攻击者真正利用的是：求职者为了不错过工作机会，愿意暂时降低平时的安全警惕。

所以判断此类骗局时，不要只问“这个 HR 说话像不像真的”，而应该看整个招聘流程是否合理。

三、一个非常重要的原则：招聘流程不应该突破你的设备安全边界

面试所需要的绝大多数事情，都可以通过浏览器、电话、短信、邮件、主流会议软件或官方招聘平台完成。

因此，如果招聘人员要求进行下面这些操作，应当直接视为高风险信号：

Android

从聊天、邮件、网盘、二维码或陌生网站下载 .apk；
打开“允许安装未知来源应用”；
要求授予短信、通讯录、电话、文件等与面试明显无关的权限；
要求开启无障碍服务（Accessibility）；
要求开启通知读取权限；
要求给予设备管理员权限；
要求安装证书、VPN 或网络代理；
要求关闭 Play Protect、手机管家或安全软件；
声称“公司内部 App 所以应用商店搜不到，这是正常的”。

iPhone / iPad

要求安装来源不明的企业签名应用；
要求安装陌生“描述文件”或 MDM 管理配置；
要求信任陌生企业开发者；
要求安装陌生 VPN、根证书或网络配置；
用“内部测试”“员工专用”等理由要求绕开正常 App Store 渠道。

单独出现其中一项不一定能够证明诈骗，但在尚未正式入职的招聘过程中出现这些要求，本身就足以暂停操作并进行独立核验。

四、真实案例：“聘聊”APK 的分析结果

下面的信息来自我收到的实际安装包及隔离环境网络抓包。

为了避免误导，结论分为“确认的事实”和“不能仅凭现有证据确认的事情”。

4.1 APK 基本信息

样本 SHA-256：

7e3511704a0a1715f0ed11857ba53384bc4b44b15fc599411b3902b925ccdb52

APK 使用了自己的签名证书，证书信息包括：

C=CN
ST=Guangxi
L=Nanning
O=Nanning GreenByte
OU=Digital Solutions
CN=Zhao Lin

证书 SHA-256：

cc714541a33c472756f5d3236719f0948b3d6ff27ba2d7a24b90e52df91d87a9

4.2 它并不像一个普通的“招聘聊天 App”

静态分析发现，这个 APK 与 Telegram Android 客户端的组件结构存在大量对应关系，但同时进行了高度混淆、加固和修改。

样本中的原生库能够看到与动态代码加载和 Android 隐藏 API 相关的特征，例如：

DexClassLoader
InMemoryDexClassLoader
setHiddenApiExemptions

Manifest 中还出现了一些需要特别关注的权限或组件，例如：

WRITE_SECURE_SETTINGS
MODIFY_PHONE_STATE
READ_LOGS
EmulatorCheckService
DaemonService
OnePxActivity

这些内容不能单独作为“它一定是木马”的证据，但对于一款通过招聘流程私下分发的所谓“聘聊”App 来说，已经足以构成严重的信任问题。

4.3 网络抓包发现的异常行为

测试在一个新建的 MuMu 模拟器中进行。模拟器没有安装其他第三方 App，也没有输入真实手机号、密码、银行卡或身份证信息。

启动 App 后，抓包发现模拟器查询了一个非常可疑的域名：

z0dxwe03.06alvtdb.org

当次 DNS 响应将其解析至：

45.197.239.150

随后客户端连接：

45.197.239.150:36121

更异常的是，该 TLS ClientHello 中携带的 SNI 是：

api.jd.com

也就是说，实际连接目标和 TLS 中声称访问的域名并不自然对应。这种现象可能涉及流量伪装等机制，至少需要非常谨慎地解释。

紧接着，客户端在极短时间内尝试连接一组分散的公网 IP 和非常规高位端口，例如：

IP	端口
`140.210.135.134`	`18743`
`218.245.101.176`	`15270`
`218.245.96.59`	`18051`
`122.9.125.220`	`18572`
`218.245.101.206`	`14317`
`122.9.49.182`	`10718`
`47.109.196.131`	`11759`
`122.9.49.79`	`21372`
`118.89.73.122`	`28292`

其中一些连接成功后开始交换非普通 HTTP 明文的二进制数据。例如，47.109.196.131:11759 出现多条并行数据连接；此前通过系统 TCP 连接观察到的 122.9.49.79:21372，也在 PCAP 中再次得到确认，并出现多条实际承载数据的会话。

与此同时，抓包也能清楚分辨出 MuMu 自己的服务，例如：

mumu.nie.netease.com
report.mumu.nie.netease.com
sigma-agentlog-mumusdk.proxima.nie.netease.com
nemu-file.fp.ps.netease.com

因此，不能简单把模拟器产生的所有网络连接都归罪于被测 App；分析时需要结合 DNS、连接建立时间、目标端口以及应用启停前后的变化进行区分。

4.4 这份分析能证明什么？不能证明什么？

能够确认的是：

这个 APK 并不是一个值得直接信任的普通招聘聊天安装包；
它经过高度修改、混淆和保护；
存在动态代码加载等值得关注的能力；
启动后会与多组非常规公网服务器和高位端口通信；
实际网络行为与一个简单的“招聘沟通工具”并不相称；
综合来源、分发方式、招聘话术和技术行为，应当按照高风险、不可信应用处理。

但目前的证据不能严谨证明：

它已经窃取了某个具体人的通讯录；
它已经窃取短信或银行卡；
某一个观察到的 IP 就一定是诈骗团伙自己拥有的服务器；
仅凭一次静态分析和 PCAP 就可以给样本下完整的恶意软件家族结论。

安全分析最忌讳把“可疑”直接写成“已证实”。

不过对于普通用户而言，你并不需要等到证明它已经偷走数据，才决定停止使用。安全决策所需的证据门槛，本来就低于恶意软件归因的证据门槛。

五、这次我是怎么排查和应对的：从收到 APK 到确认高风险

这次经历对我来说最有价值的，不只是最后发现了一批异常 IP，而是形成了一套以后再遇到类似情况也可以复用的处理思路。

整个过程最核心的原则是：

先控制风险，再收集证据；先做隔离，再谈分析。

如果一开始就把未知 APK 装进自己的主力手机，即使后面分析出了问题，也已经很难回答“它在分析之前到底读取过什么”。

下面按照这次实际处理的顺序记录。

5.1 第一步：觉得不对劲时，没有在真实手机上继续操作

收到“聘聊”安装链接后，我首先注意到一个问题：

这是求职沟通，却要求通过一个陌生链接下载专门的 App，而且对方还会根据 Android / iOS 系统给出不同的安装方式。

因此我没有：

在自己的真实 Android 手机上安装；
输入真实手机号；
输入短信验证码；
登录自己的常用账号；
提交身份证、银行卡等信息。

这是整个处理过程中最重要的一步。

如果一个文件可能有问题，最好的安全措施不是事后杀毒，而是一开始就不给它接触真实数据的机会。

5.2 第二步：保留原始 APK，并计算文件哈希

拿到 APK 后，没有修改原文件，而是先保留样本并计算 SHA-256：

7e3511704a0a1715f0ed11857ba53384bc4b44b15fc599411b3902b925ccdb52

哈希的意义类似文件“指纹”。

后续即使文件改名，也可以用 SHA-256 判断讨论的是不是同一个样本。在举报、复核以及与其他安全研究结果对比时，这比“聘聊.apk”这样的文件名可靠得多。

实际遇到类似事件时，建议同时保存：

原始下载 URL；
原始邮件；
文件名；
SHA-256；
收到文件的时间；
对方要求安装文件的聊天记录。

5.3 第三步：使用全新的 Android 模拟器进行隔离

因为需要确认 App 到底会做什么，我没有使用真实手机，而是新安装了 MuMu，并使用一个干净的模拟器实例。

这个实例中：

没有我的真实聊天记录；
没有真实通讯录；
没有银行卡和支付 App；
没有个人照片；
没有登录我的常用账号；
除“聘聊”外没有再安装其他第三方 App。

这样做有两个好处。

第一是隔离风险。即使 App 存在读取通讯录、相册或其他隐私数据的行为，测试环境里也没有真正有价值的个人数据。

第二是降低分析噪声。一个装了几十个 App 的模拟器会不停产生后台网络连接，很难判断某个 IP 到底是谁访问的。干净环境更容易比较 App 启动前后的差异。

需要说明的是：模拟器不是绝对安全沙箱。 对普通用户来说，如果没有分析需要，最稳妥的选择依然是不运行未知 APK。

5.4 第四步：先做 APK 静态分析，不急着“点进去看看”

在进一步操作 App 之前，对 APK 做了静态检查，主要观察：

包结构和组件；
AndroidManifest；
权限；
签名证书；
DEX；
Native .so；
是否存在明显加固、混淆；
是否具有动态加载代码的能力。

这个阶段发现了前文提到的几个重要现象：它具有非常明显的 Telegram 衍生结构，同时又进行了重度混淆/保护，并出现 DexClassLoader、InMemoryDexClassLoader、setHiddenApiExemptions 等值得警惕的特征。

这一步没有直接得出“它就是木马”的结论，而是得到一个更实际的判断：

样本复杂度和能力已经远超我对一个普通招聘聊天 App 的合理预期，应该继续按高风险样本隔离观察。

5.5 第五步：用 TCP 连接变化定位“启动 App 后多出来的服务器”

接下来使用 TCPView 观察 Windows / 模拟器相关网络连接。

这里没有简单地看到一个陌生 IP 就下结论，而是进行了对照：

记录 App 运行时的连接；
强制停止“聘聊”；
再观察哪些连接随 App 一起消失；
对仍然存在的连接继续保留怀疑，但暂时不归因给“聘聊”。

这个方法很有效。

例如当时重点看到：

122.9.49.79:21372
122.9.49.79:22234
8.134.237.207:17754

其中一些连接在 App 被强制停止后同步消失，因此与被测 App 的相关性明显升高。

相反，118.123.20.59:443 当时仍然存在，所以没有直接把它归入“聘聊服务器”。后续 PCAP 中的 DNS 记录进一步显示它与：

nemu-file.fp.ps.netease.com

有关，更符合 MuMu 自身服务。

这个过程也提醒我：

分析网络行为时，“某 IP 出现在任务管理器/TCPView 里”不等于“这个 IP 属于恶意 App”。启停对照和 DNS 对应关系非常重要。

5.6 第六步：使用 Wireshark 抓包，而不是只看“连到了谁”

TCPView 可以告诉我们建立了哪些连接，但无法完整回答连接前后的 DNS、协议特征和时间关系。

因此进一步用 Wireshark 抓取网络流量，并保存为 PCAPNG 文件。

测试过程中仍然坚持：

不输入真实手机号；
不输入验证码；
不登录真实账号；
只进行足以触发基础网络行为的操作。

原本重点关注：

122.9.49.79
8.134.237.207

实际抓包文件里还包含其他系统/模拟器流量，因此后续分析没有假设“PCAP 里所有东西都是聘聊产生的”，而是根据模拟器 IP、TCP SYN、新建连接时间、DNS 查询及目标端口重新筛选。

这一步非常重要。如果抓包范围过大，不应该直接丢弃整个结果，更不能把全部流量算到目标 App 头上；仍然可以利用时间线和端点进行过滤。

5.7 第七步：把 DNS、TCP 建连和应用行为串成时间线

真正让我把风险评级进一步提高的，是把流量按时间排序以后出现了很清晰的链条。

北京时间约 21:25:46，模拟器查询：

z0dxwe03.06alvtdb.org

DNS 返回：

45.197.239.150

紧接着连接：

45.197.239.150:36121

TLS ClientHello 中却能够看到：

api.jd.com

随后又在极短时间内尝试连接多组公网 IP 和随机高位端口，并在部分节点上真正开始交换数据。

之前 TCPView 中出现的 122.9.49.79:21372 也在 PCAP 中重新出现，而且观察到了多条实际承载二进制数据的 TCP 会话。

这就完成了从：

TCPView 发现异常连接
        ↓
App 停止后连接变化
        ↓
PCAP 再次捕获相同服务器
        ↓
DNS + 时间线定位新的可疑基础设施
        ↓
观察到实际二进制数据交换

的一次交叉验证。

单个现象可能有很多解释，但多个独立证据互相对应以后，判断的可靠性就会高很多。

5.8 第八步：没有因为“发现异常”就继续输入真实资料测试

这是分析过程中很容易犯的错误。

看到 App 行为可疑之后，有人可能会想：

“那我输一个真实手机号，看看下一步它会不会偷验证码。”

实际上完全没有必要。

安全分析的目标是控制风险并获得足够做出决定的证据，不是非要亲自走完整个攻击流程。

当静态特征、来源、分发方式以及网络行为已经共同达到“不值得信任”的程度时，就已经足够做出不在真实设备使用的决定。

因此这次没有向 App 输入任何真实身份信息。

5.9 第九步：最终处置——测试环境用完即弃

由于 MuMu 是为了此次测试刚刚安装，模拟器内部也没有个人数据，测试结束后的处理非常简单：

不再运行“聘聊”；
保留用于举证的 APK 哈希、必要截图和 PCAP；
删除被测 APK；
不将 APK 安装到真实手机；
不再使用该模拟器实例，直接删除整个测试实例更干净；
Windows 使用系统安全软件进行一次完整扫描；
检查测试过程中是否给模拟器挂载过包含私人资料的共享目录。

由于整个测试没有输入真实手机号、验证码、账号密码、身份证、银行卡等信息，也没有把真实手机环境暴露给 APK，因此没有必要仅因为这次隔离测试就立即修改全部账号密码或重装 Windows。

如果实际情况相反——例如已经在主力手机安装并给予高危权限、输入账号或上传身份证——处置级别就必须相应提高，参考前文“已经安装了陌生招聘 App 怎么办”。

5.10 把这次方法总结成一个可复用的排查流程

阶段	做什么	目的
发现异常	停止在真实手机继续操作	先保护真实数据
固定证据	保存 URL、邮件、APK、SHA-256	防止后续样本变化或链接失效
建立隔离环境	使用无账号、无个人数据的全新测试实例	降低运行未知程序的后果
静态分析	看签名、权限、组件、DEX、SO、动态加载	不运行也能发现高风险特征
建立基线	观察 App 未运行时的网络连接	知道哪些流量本来就存在
动态对照	启动/强制停止 App，对比 TCP 连接	找到与 App 高度相关的端点
网络抓包	保存 DNS、TCP、TLS 等流量	获得比连接列表更完整的证据
关联分析	按时间串起 DNS → IP → 端口 → 数据	避免凭单个 IP 草率归因
风险决策	达到“不可信”阈值后停止深入交互	不为证明恶意而主动暴露真实数据
善后	删除测试实例、扫描宿主机、保存必要证据	清理环境并为举报/复核留证

对普通用户而言，并不需要完成表中所有技术分析。

事实上，如果已经出现“招聘人员要求通过陌生链接安装未知 APK”，最安全的普通用户流程只有四步：

不安装 → 截图留证 → 通过公司官方渠道独立核实 → 举报/拉黑

后面的模拟器、静态分析、TCPView 和 Wireshark 都属于“为了搞清楚它到底在做什么”的研究手段，而不是每个求职者都应该冒险完成的步骤。

六、我总结的“招聘 App 防骗红线”

以后遇到招聘，只要命中下面任意一条，我都会先停止操作：

面试前要求安装非官方渠道 App。
下载地址不是公司官网或正规应用商店。
HR 特别询问 Android / iOS，然后分别发送不同安装方法。
用“试岗”“培训”“内部沟通”“保密项目”等理由解释为什么必须安装。
要求关闭手机安全功能。
要求无障碍、设备管理、短信、通讯录、屏幕共享等明显超出招聘需要的权限。
招聘岗位在公司的官方招聘网站上无法找到。
网上能找到公司，但找不到联系你的 HR 或对应岗位。
招聘信息来自第三方平台，但对方急于把交流转移到完全陌生的平台。
不愿通过公司官网公布的电话、邮箱等独立渠道接受身份核验。
强调“名额马上没有”“今天必须完成”“不安装就取消资格”。
尚未正式入职就要求身份证正反面、银行卡、验证码、支付密码等敏感信息。

这里特别提醒一点：

“公司是真的”不等于“正在联系你的人是真的”。

诈骗者完全可以冒用真实公司名称、Logo、地址、员工姓名以及已经过期的招聘信息。

七、收到招聘邀请，正确的核验方法

第一步：不要使用对方提供的联系方式进行“自我验证”

如果骗子告诉你：

“不信可以打这个公司电话。”

然后给你一个号码，你再拨这个号码，实际上没有完成任何独立核验。

正确方法是自己打开公司的官方网站，从官网重新寻找总机、招聘邮箱或 HR 联系方式。

第二步：交叉核对岗位

分别查看：

公司官方网站的招聘页面；
招聘平台当前仍在招聘的职位；
公司认证账号；
岗位名称、办公地点、职位描述和招聘主体是否一致。

如果对方利用的是已经下架的旧岗位，应直接联系公司官方渠道核实。

第三步：检查邮件地址

重点看 @ 后面的完整域名，而不是发件人显示名称。

“XX 公司招聘负责人”这个显示名称任何人都可以填写。

即使邮箱域名看起来很像，也要注意字母替换、多一个连字符、相似字符和免费邮箱。

第四步：反向提问

可以直接问：

这个职位在公司官网的招聘链接是什么？
招聘部门和职位编号是什么？
为什么面试必须安装这个 App？
是否可以使用腾讯会议、Teams、Zoom、电话等常见方式完成面试？
App 在 Apple App Store / 正规 Android 应用市场的官方页面在哪里？
App 的开发者主体与招聘公司是什么关系？

真正正常的招聘人员不应该害怕求职者进行合理的安全核验。

八、已经安装了陌生招聘 App 怎么办？

先不要恐慌，也不要为了“看看它到底还会干什么”继续操作。

情况 A：刚安装，没有输入任何真实信息

风险相对较低。

建议：

立即停止使用；
断开 App 的网络访问；
检查它获得了哪些特殊权限；
撤销无障碍、设备管理员、VPN、通知访问等权限后卸载；
用系统自带安全功能进行扫描；
如果 App 获得过非常高的系统权限，或者无法确认其行为，重要数据备份后恢复出厂设置是更稳妥的选择。

情况 B：输入过账号密码

请在另一台可信设备上：

修改密码；
退出其他登录会话；
开启双因素认证；
如果相同密码在其他网站复用，全部更换。

情况 C：输入过短信验证码

立即检查与验证码对应的服务，不要只删除 App。

重点查看：

银行和支付账户；
邮箱；
微信、QQ 等社交账号；
手机运营商账号；
招聘平台账号；
是否出现陌生登录设备或新授权。

情况 D：提交过身份证、银行卡、人脸或其他实名材料

保存证据，并持续关注身份冒用、异常开户、支付和账号找回风险。发生财产损失或明确诈骗行为时，应及时联系相关平台、银行/支付机构并报警。

情况 E：安装在电脑 Android 模拟器里

如果模拟器是全新创建、没有登录真实账号、没有共享私人文件，通常比直接安装在主力手机上安全得多。

处理方式可以很简单：

删除整个模拟器实例；
删除 APK；
检查模拟器是否配置了 Windows 共享文件夹；
Windows 安全中心执行一次完整扫描。

没有其他异常迹象时，不必因为在隔离模拟器运行过一次 APK 就直接重装整台电脑。

九、如果想自己检查 APK，最低限度可以做什么

普通用户不建议在真实手机上“以身试毒”。

如果具备一定技术能力，可以在与个人环境隔离的测试设备/虚拟机里分析，至少记录：

APK 的 SHA-256；
APK 签名证书；
包名；
Android 权限；
域名和 IP；
TCP/UDP 目标端口；
App 启动、停止前后的网络连接差异；
是否动态加载 DEX / SO；
是否申请无障碍、设备管理、VPN、短信等高风险能力。

但务必注意：

“杀毒网站显示 0 家报毒”不等于安全。

新样本、定制样本、重度加固样本，本来就可能暂时没有特征库命中。反过来，一两个引擎的启发式报警也不能单独证明恶意。应该综合来源、行为、权限、签名和网络通信判断。

十、为什么“急着找工作”时更应该慢一分钟

这类攻击最让人不舒服的地方，是它针对的正是一个人比较焦虑的时候。

求职者可能已经失业了一段时间，可能急着交房租，也可能是刚毕业、第一次面对社会招聘。此时突然收到一封看起来很正式的邮件，对方知道你的技术方向、目标城市，告诉你“有一个机会很适合”，很容易让人主动替所有异常行为寻找合理解释。

但我们可以记住：

真正值得去的工作，不会以牺牲你最基本的设备和账号安全为入场券。

对方越催，越要慢下来。

安装一个陌生 APK 可能只需要 20 秒，但手机里面可能有你的：

手机号和通讯录；
短信与验证码；
工作邮件；
聊天记录；
登录凭据；
相册与身份证照片；
银行和支付应用；
云盘；
甚至公司内部资料。

任何一个招聘机会都不值得拿这些东西下注。

十一、给正在找工作的朋友一份 30 秒检查表

收到陌生招聘邀请时，先问自己：

我是否真的投递过这家公司？
这个岗位现在还能在公司官方渠道找到吗？
联系人的邮箱域名真的是公司域名吗？
我有没有通过自己找到的官方联系方式再次核验？
对方是否要求离开正常招聘平台？
是否要求下载官方应用商店之外的软件？
是否要求打开未知来源、企业信任、描述文件或特殊系统权限？
App 要求的权限和“招聘/面试”功能真的有关吗？
对方是否在制造“马上操作，否则失去机会”的紧迫感？
如果这不是一个工作机会，我还会放心做这些操作吗？

最后一题如果答案是“不”，就不要因为“这是招聘”而破例。

十二、保留证据并帮助下一位求职者

发现可疑招聘后，不要急着清空所有聊天记录。

先保留：

招聘邮件原文及邮件头；
对方邮箱、手机号和账号；
招聘平台职位链接；
下载链接；
APK 文件或至少保存其 SHA-256；
App 名称、包名和截图；
对方要求安装软件、试岗、培训的聊天记录；
付款记录（如果有）；
时间线。

然后向招聘平台和被冒用的公司举报。如果已经发生诈骗、财产损失或账号被盗，应及时联系相关服务商并向警方报案。

公开分享案例时，建议隐藏自己的手机号、身份证号、家庭住址、邮箱 Token、Cookie、验证码等敏感数据，也不要在没有充分证据的情况下把某个真实企业或个人直接定性为诈骗主体——存在公司被冒用、服务器被租用甚至基础设施被入侵的可能。

结语

写这篇文章不是为了让大家对所有招聘人员产生怀疑，而是希望大家建立一条清晰的安全底线。

骗子可以复制企业 Logo，可以复制招聘 JD，可以知道你的求职城市，可以注册一个非常像真的邮箱，也可以做一个看起来很正常的聊天 App。

但我们仍然有一个非常有效的防御方法：

不要按照对方为你设计的路径一路走到底。

自己找官网、自己找电话号码、自己核实岗位、自己确认软件来源。

特别是在对方说：

“先安装这个内部 App，我们在里面沟通。”

请停下来。

一次工作机会可以再找，泄露出去的身份信息、账号和隐私却很难真正收回来。

如果这篇文章能让一个正在焦急找工作的人，在点击“安装”之前多犹豫一分钟，它就有价值。

附：本文案例的技术指标（IOC）

以下指标仅代表本次样本/本次测试时观察到的行为，用于研究和排查。不要仅凭某个 IP、域名或证书命中，就直接认定某个主体参与诈骗。 云服务器、CDN、共享地址及被入侵主机都可能造成误判。

文件

SHA-256: 7e3511704a0a1715f0ed11857ba53384bc4b44b15fc599411b3902b925ccdb52

签名证书

SHA-256: cc714541a33c472756f5d3236719f0948b3d6ff27ba2d7a24b90e52df91d87a9
Subject: C=CN, ST=Guangxi, L=Nanning, O=Nanning GreenByte, OU=Digital Solutions, CN=Zhao Lin

测试中重点观察到的网络指标

z0dxwe03.06alvtdb.org
45.197.239.150:36121
47.109.196.131:11759
47.109.196.131:12673
122.9.49.79:21372
122.9.49.79:22234
118.89.73.122:28292
118.89.73.122:29197
218.245.101.206:14317

抓包时间：2026-10-04（北京时间）。

声明： 本文用于个人安全研究与反诈骗科普。案例中的技术判断基于当时取得的样本及隔离环境流量，不代表对相关 IP 所属云服务商、域名注册服务商、被冒用企业或其他基础设施提供方作任何违法行为指控。