写在前面

这次受骗的是老板本人。经他同意，本文保留两次付款、团队劝阻和判断失误的完整过程，也把后续技术核查的权限边界讲清楚。

事情起于一次威胁情报补充工作。团队需要持续跟踪勒索团伙、数据泄露和网络访问权限交易等信息。原RAMP论坛被查封后，一个自称“RAMP4U回归”的新站点进入视野，老板准备注册账号，核实站内内容是否具有继续跟踪的价值。

熟悉威胁情报的读者对RAMP不会陌生。RAMP于2021年上线，曾是少数公开允许推广勒索软件合作的网络犯罪论坛之一，内容包括恶意软件、网络访问权限、数据泄露和勒索软件加盟招募。2026年1月28日，原RAMP论坛使用的明网域名 ramp4u[.]io 及其Tor站点出现FBI查封通知，域名服务器也切换至FBI查封域名时常用的服务器。

本次涉及的是另一个域名：ramp4u[.]com。该站借用了原RAMP的页面风格和“回归”说法。对长期跟踪这类社区的人来说，核实它究竟是原站迁移、他人镜像，还是新出现的仿冒站，本身有工作价值。但后续事实证明，研究工作只能解释为什么会访问和准备注册，不能替代付款前的身份核验。
)

仿冒站沿用了原RAMP的名称、配色、栏目和勒索软件广告

Solar应急响应团队对受骗经过、沟通记录、站点源码和RAMP业务数据库进行了复盘。本文将说明这类平台如何建立可信度，如何通过人工审核和追加费用诱导连续付款，以及技术核查如何确认其虚假论坛数据和凭证钓鱼行为。

本文不公开可直接复现的漏洞利用步骤、服务器账号、数据库口令、支付密钥、WebShell密钥、其他付款人的个人信息和受害者明文凭证。技术核查只用于固定证据、风险预警和防御分析，不建议读者未经授权访问或控制他人系统。

两次付款后账号仍未开通

2026年10月30日，老板按照注册页面的要求支付了第一笔500美元，付款页面折合人民币约3400元。

封闭情报社区通过收费筛选成员并不罕见，部分社区还会收取注册费、保证金或订阅费。页面相似、原站刚被查封、新站自称回归，再加上行业确实存在付费情报渠道，共同构成了第一笔付款的背景。回头看，付款前没有通过独立渠道充分核验新域名、运营主体和退款条件，这是第一处判断失误。

第一笔注册费为500美元，页面要求向指定地址支付比特币

付款完成后，平台没有立即开通账号，而是显示“账户正在审核中”，声称工作人员通常会在10至30分钟内回复。

付款成功后，页面将账号状态转为人工审核，并未直接交付账号

等待接近一天后，账号仍无法使用。老板授权安排给其它同事进行沟通，接着通过平台预留的联系方式询问，对方先以人工审核为由解释，随后提出还需要支付1000美元，才能继续完成开通流程。

团队当时已经判断其中存在明显风险，劝阻继续付款。老板当时仍用封闭情报社区的成本解释这项收费，原话是：

“这个价格是正常的”

“所以这些很多威胁情报为什么价格贵，就是因为成本就很高”

这两句话能够说明他当时的判断依据，但不能证明平台收费合理。社区是否存在运营成本，与这个收款主体是否可信，是两个问题。对方没有提供可核验的主体信息、服务条款和退款保障，却在首款未交付时追加第二笔费用，风险已经十分明确。

团队继续劝阻，老板的回应是：

“我前面都支付500美元了，如果这1000美元不付，那么我这500美元不就白付了吗”

这句话就是整个事件最需要复盘的地方：第二笔付款不是因为新证据证明了平台可信，而是此前的500美元已经成了继续付款的理由。

客服以人工审核和账户开通为由持续拖延，并引导继续沟通付款

最终，老板又支付了1000美元，按当时付款页面折算约6880元。两次付款合计1500美元，折合人民币一万余元。

第二笔付款金额提高到1000美元，收款页面与首次页面并不相同

需要修正一个常见判断：跳转到第三方支付页面，本身不能证明平台是诈骗。 正常服务也会使用第三方支付和加密货币收款通道。真正需要警惕的是，收款主体无法核验，支付页面频繁变化，退款规则缺失，客服在付款后不断增加保证金、解冻费或重新注册费。

第二笔付款完成后，对方又称发票时间多次延长，注册无法自动完成，要求重新注册，并表示会将已付款项转入新账户。按照这一说法，还需要再次执行注册和付款流程。

诈骗平台管理员称：“注册无法自动完成”

此后，ramp4u[.]com 一度无法访问。约一天后网站恢复，使用此前注册的账号登录，页面提示登录信息不正确。直到这时，账号仍未开通，对方承诺的转款和激活也没有完成。

网站恢复后，此前注册的账号仍提示登录信息不正确

这次事件随后被用于团队内部安全意识与反诈培训。培训没有回避老板的两次付款，也没有把问题归结为一句“缺乏安全意识”。真正需要识别的是，已经投入的资金如何影响下一次判断。

团队成员“州弟学安全（徐龙州）”此前录制反诈视频，其中套路如出一辙

CDN后面的管理主机

事件进入技术复盘后，首先要确认站点基础设施。核查时，ramp4u[.]com 的普通DNS解析指向Cloudflare地址。Cloudflare地址只是代理入口，不能直接当作源站地址。

ramp4u解析至Cloudflare代理入口

对同域名的常见管理端口进行核验时，团队发现2083端口提供cPanel入口。访问cPanel OpenID Connect流程后，页面跳转至 ro-s2.serverpanel.com:2083，由此取得实际管理主机名。该主机名解析到 185.93.222.2。

2083端口开放cPannel服务

这里需要区分两个结论：管理端口跳转可以确认与目标站关联的cPanel管理主机，但仅凭一次跳转和解析，还不能把该地址直接写成全部Web业务的唯一源站。 后续还要结合错误页、服务商信息、站点目录和数据库配置交叉验证。

cPanel OpenID Connect页面跳转到了实际管理主机名

继续访问管理主机上不存在的路径，cPanel默认错误页返回了服务商联系邮箱 alerts@shockhosting.com。邮箱域名指向ShockHosting，公开主机信息和IP归属也提供了对应关系。至此，管理主机名、管理端口、错误页、服务商网站和IP归属形成了多维印证。

默认错误页暴露了服务商联系邮箱，为归属核查提供了线索

针对管理主机名域名进行ping操作获取实际IP

针对此IP获取服务商归属确认为shockhosting

服务商和IP归属只说明基础设施被谁提供，不能据此认定服务商知情或参与诈骗，也不能据此判断操作者的国籍和实际所在地。

一个共享主机账户能做什么

团队随后在同一服务商、同一 ro-s2 管理环境中开通了一个新的cPanel账户。并发现该服务商存在计费漏洞，该问题现已修复，本文不公开复现步骤。

新账户与 ramp4u[.]com 位于同一管理主机，但分属不同租户。这里所说的“空间”，准确含义是cPanel共享虚拟主机账户，不是一台归用户独占的云服务器。

共享虚拟主机可以理解为同一套操作系统中的多个租户。每个租户通常拥有自己的 /home/用户名/ 目录、网站、数据库和邮箱，可以在自己的目录中上传文件、配置站点，并以自己的系统用户身份运行PHP等服务端程序。

普通租户不直接拥有以下权限：

• 操作系统root权限；
• 读取其他租户目录的权限；
• 修改全局Web、数据库和备份服务配置的权限；
• 管理整台服务器的权限。

这台管理主机底层是物理机还是服务商进一步划分的VPS，现有材料不能判断，文章不作延伸结论。

cPanel终端从当前账户的家目录启动，此时只有普通租户权限

突破CageFS视图仍不是root

共享主机通常使用CageFS等机制限制租户可见的文件系统。初始终端中，账户只能看到CageFS提供的有限 /var/log 内容，部分系统目录返回 Permission denied，进程视图也受到限制。

后续测试利用 .forward 邮件投递管道，使同一租户身份的进程在邮件投递上下文中运行。该进程看到了更大的宿主机挂载视图，包括更完整的 /var/log，但UID没有改变，/etc/shadow 仍返回权限不足。

因此，这一阶段的准确结论是：租户进程突破了CageFS文件系统视图限制，但仍以普通租户身份运行。 看见更多文件，不等于有权读取所有文件，更不等于已经取得root。

邮件投递上下文中的进程仍以普通租户UID运行，但能看到更完整的宿主机日志目录

MongoDB密码与chisel代理

在前期测试时，宿主机一份软件安装日志记录了JetBackup读取本地MongoDB认证信息的过程，其中包含管理员口令，而相关日志对普通用户可读。这是敏感信息进入安装日志与文件权限配置过宽共同造成的问题，不是MongoDB主动把口令提供给远程用户。

该路径目前已经无法复现。 后续核查时，/var/log/dnf.rpm.log 疑似已被运维清理或删除，团队不能再次从原位置取得相同内容。本地保留了前期测试时取得的口令，因此可以继续验证后续数据库连接和权限链。公开文章不展示该口令，也不把无法复现的环节写成当前仍然有效。

JetBackup使用的MongoDB只监听服务器本机地址，不能从外部分析环境直接连接。新开通的cPanel空间又缺少图形化MongoDB客户端及相应的本地分析条件，因此团队使用chisel建立TCP转发，将服务器本机的MongoDB端口映射到有客户端的分析环境。

chisel只是TCP代理工具，作用是把网络连接接到目标本机端口，不负责提权，也不会把普通租户变成root。 真正影响后续权限的是已经泄露的数据库口令，以及备份软件对高权限配置的处理方式。

在VPS使用chisel开启一个隧道代理

在cPanel上传chisel用于连接隧道代理

分析端通过本地转发端口连接JetBackup使用的MongoDB

JetBackup任务最终形成root执行

JetBackup 5是常见的cPanel备份与恢复软件。主机商用它备份和恢复网站文件、数据库、邮件及账户配置。由于备份任务需要跨租户读取数据，相关服务必须具备较高的系统权限。JetBackup 5还使用本地MongoDB保存用户、任务、日志和配置。

进入该MongoDB后，团队调整了测试账户在JetBackup中的权限标识。需要注意，备份系统中的管理权限不等于Linux root。 它只是允许账户调用更多备份管理功能，真正的权限跃迁发生在后续任务执行阶段。

修改自身账户权限标识为true

进一步核查发现，备份配置允许指定任务调用的压缩程序路径，而备份服务会以高权限执行相关程序。团队在测试账户目录中准备了验证脚本，通过备份配置和任务触发，让服务调用该脚本，并记录实际UID、父进程和权限结果。

验证过程记录了JetBackup配置、任务调用和脚本执行结果

最终回显中出现 uid=0(root)，父进程为 jetbackup5d 备份任务。到这一步，才能确认测试账户控制的代码已经以宿主机root权限执行。

任务回显显示uid=0(root)，父进程为JetBackup备份服务

为什么取得root后才能读取其他租户文件和数据库？

在普通租户阶段，Linux文件权限和CageFS视图共同限制了可访问范围。root进程则能够越过常规文件属主和权限位限制，并读取全局服务配置、其他租户家目录及数据库认证信息。root意味着具备读取这些数据的权限，不等于已经把所有数据提取出来。

本次核查最终具备读取该站点全部数据库以及同机其他租户文件和数据库的权限。为控制数据接触范围，数据库分析仅提取RAMP相关业务表，没有提取服务器上的全部数据库内容，也没有对同机其他租户业务数据展开统计。代码快照中另发现WWH-Club仿冒页面，后文仅说明其钓鱼用途和证据边界。

仿冒站的代码与数据

取得的目录快照包含960个文件，约329 MB。其中，RAMP4U主站包含57个PHP文件，约8843行PHP代码。静态审计没有发现XenForo核心、模板或插件，说明这不是原RAMP论坛的源码或官方镜像，而是一套自行编写、外观模仿XenForo的PHP程序。

这套程序具备注册、支付、帖子展示和会员展示等功能，但大量“社区活跃数据”由程序生成。它同时包含支付接口、Telegram通知、人工审核和虚假内容轮换等模块。

以下统计仅来自本次取得的RAMP业务库快照，时间覆盖至2026年11月2日。数据只反映该仿冒站在这一时点的状态，不代表原RAMP论坛，也不代表其他网络犯罪社区。

实际查询得到18,497条主题和38,409条帖子记录

38,409条帖子记录只有80种正文。其中，同一句“Staff-checked listing”出现了11,708次。其他高频正文还包括“Welcome aboard”“Subscribed”“Noted, will follow up tomorrow”等固定短句。

这意味着，页面上的大量帖子并不是对应数量的真实讨论。程序只需要轮换标题、作者、时间和浏览量，就能制造出持续活跃的表象。

高频帖子正文为固定英文模板，同一段内容最多重复11,708次

主题表中的 reply_count 合计为522,893，但实际帖子表只有38,409行。即使考虑主题首帖和统计口径差异，两组数据也无法形成合理对应。浏览量同样由程序维护，不能作为真实用户规模的证明。

在线人数也是独立维护的展示值。状态表中的 online_count 为171，online_guests 为97，online_record 为241，并配有下一次在线数据更新时间。它与实际账户表记录数量没有直接关系。

另一个关键差异出现在账户表。ramp_forum_users 中有417个用于论坛展示的账号，而保存注册邮箱、密码散列和支付订单关联信息的 ramp_users 只有2条记录，前台会员数却显示为418,838。

实际账户表只有2条记录，与前台会员数存在明显差异

因此，会员数量、在线人数、帖子数量和“已验证泄露库”都不能作为平台可信度的依据。对这类封闭社区而言，页面越热闹，越需要核验这些数据是否有真实业务支撑。

付款完成不等于账号开通

RAMP业务库中有299条注册支付订单，每笔订单标价均为500美元。订单状态如下：

299笔订单中只有4笔标记为completed

4笔 completed 订单合计2000美元，但4笔订单的审核状态全部为 pending，账户开通消耗字段均为空。也就是说，支付接口已经确认付款，不等于平台已经交付账号。

完成支付的订单仍停留在pending审核状态，账号交付并未完成

老板的首笔500美元付款能够在当前订单表中找到对应记录。第二张1000美元付款截图来自另一个外部付款页面，未出现在这张Plisio订单表中，因此不纳入上述2000美元统计。老板累计损失1500美元的结论来自付款和沟通材料，不是对平台全部订单的推算。

同时，4笔完成订单不等于已经核实4名独立受害者，也不能代表该平台的全部非法所得。本文只使用聚合数据，不公开其他付款人的邮箱、IP地址、订单号和交易标识。

这套流程解释了客服为什么反复强调人工审核。在这里，人工审核不是有效的交付保障，而是付款后的拖延工具。只要账号始终处于待审核状态，对方就可以继续以发票超时、保证金、重新注册和转移余额为由要求追加操作。

另一条钓鱼线指向WWH-Club

代码快照中还出现了针对WWH-Club用户的凭证钓鱼内容，这里需要先说明WWH-Club是什么。

WWH-Club是2012年前后出现的俄语网络犯罪论坛和交易市场，长期涉及被盗银行卡数据、账户日志、网络访问权限、恶意软件和欺诈教学，不是普通的网络安全技术社区。

本案快照中出现的是仿冒WWH-Club登录和重置流程的代码，不代表WWH-Club官方站点被控制，也不代表该站运营方参与本案。

快照中的相关目录使用 wwh-club.net 和 wwh-club.org 等名称，页面来自“Save Page WE”保存的静态镜像。登录表单被改为向本地 login/auth.php 提交，而不是提交到真实论坛服务。该脚本会记录用户名、密码、Secret Word、passphrase hash、IP地址、国家和网络服务提供商等信息，并将部分内容写入文本文件。

静态页面被改造成凭证收集入口，输入内容会进入仿冒站后台

脚本会记录登录信息、二次验证信息和IP归属

代码审计报告对快照中文本文件的统计为11,319条登录尝试，涉及1,967个唯一用户名和2,834个唯一密码，其中10,239条带Secret Word，1,867条带Hash，记录时间为2026年8月21日至11月2日。

被钓鱼成功的人员信息会保存至txt文档

这些数字只描述本次快照中的文本记录。登录尝试不等于成功入侵账户，唯一用户名也不等于独立受害者人数，其中还可能包含错误输入、重复尝试和测试数据。本文不展示任何明文密码、二次验证秘密词或可用于登录的信息。

这部分发现说明，同一套基础设施不仅用于收取注册费，还被用于收集其他论坛的账户凭证。对威胁情报从业者来说，在不同论坛之间复用用户名、密码、邮箱和二次验证信息，会进一步扩大损失。

这套骗局的完整流程

结合受骗经过、代码和数据库，可以将这类平台的流程归纳为七步。

这类骗局的关键不在于页面做得是否精细，而在于每一步都只要求访问者再等待一次、再支付一次。只要继续付款的理由变成“已经投入这么多”，后续要求就可能不断升级。

溯源结果与归因边界

以下为核查时的主要关联资产。域名和IP状态可能变化，只用于事件复盘、日志排查和风险预警。

代码和日志中出现了Proton VPN、Cloudflare、托管服务商和支付通道等名称。这些记录只能说明相关服务被使用，不能据此认定服务商知情或参与诈骗。VPN出口、代理地址和服务器归属地也不能单独用于判断操作者国籍、身份或实际所在地。

同样，代码中的勒索软件品牌、团伙名称和所谓官方合作文案，多数用于搜索优化和借名背书。当前证据不能证明该站点与Babuk、GLOBAL GROUP、LockBit、Qilin等真实勒索团伙存在运营关系。

个人和企业如何防

威胁情报从业者需要额外谨慎

第一：先核验域名，不只看页面。原站查封、迁移或关闭后，近似域名可能快速出现。应通过多个独立来源核对域名历史、原站公告和可信威胁情报，不以搜索排名、页面相似度和Telegram回复作为身份依据。

第二：不把加密货币预付当作普通网购。付款前需要确认收款主体、订单条款、退款条件和争议处理方式。无法确认这些信息时，不支付所谓注册费、保证金或解冻费。

第三：不在不同论坛复用凭证。研究账号应使用独立邮箱、独立密码和独立二次验证方式，不在工作设备上保存其他论坛的真实登录信息。

第四：在隔离环境中访问未知社区。使用与工作资料隔离的虚拟机和网络环境，不直接在生产办公机上打开未知附件、源码和压缩包。

企业需要建立止损流程

企业为威胁情报、漏洞研究和暗网监测提供资源时，应同时建立明确的费用审批和异常上报流程。研究账号、研究设备和研究预算应与员工个人账号、个人资金分开。

发现员工可能受骗时，应先停止付款和固定证据，而不是先追责。担心被批评，会让当事人延迟上报，也会给不法人员留下更多操纵时间。

安全培训不能只讲陌生链接和钓鱼邮件，还应覆盖品牌仿冒、虚假社区、加密货币付款、人工审核拖延和沉没成本。对研究岗位而言，这些风险比常规钓鱼邮件更接近日常工作。

已经付款后怎么处理

1. 立即停止后续付款，不因“最后一笔”“立即解冻”等话术继续投入。
2. 保存网站地址、注册信息、聊天记录、订单号、交易哈希、收款地址和付款页面截图。
3. 联系支付通道、交易平台或金融机构说明情况，询问是否存在止付、投诉和争议处理渠道。
4. 及时报警，并按司法机关要求提交原始证据，不在公开群中传播完整个人信息和交易凭证。
5. 如果在仿冒站复用过其他平台密码，应立即修改相关账号密码和二次验证信息，并检查登录记录。
6. 企业应排查相关域名和IP的访问日志，但不要为了继续取证而扩大未授权访问。