文章总结： 本文基于公安部通报的四川宜宾某票务系统被植入后门管理账户、数据被批量导出且长期未被发现的案例，提出排查思路。核心观点是运维团队不应只关注系统是否宕机，而应主动核查陌生管理账户来源、登录终端及数据导出路径。文章将异常传输拆解为入口、控制、导出、长期未发现四阶段，并给出账号对账、取证顺序及四条防守行动建议，强调系统无报错不等于数据边界正常。
综合评分： 88
文章分类： 应急响应,漏洞分析,红队,内网渗透,安全运营
票务系统没停，云服务器却多了个陌生管理账户
原创
tcode
tcode
字节脉搏实验室
2026年9月23日 12:31
北京
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
景区闸机照常开，售票页面照常卖，运维人员也没有收到宕机告警，但票务系统的云服务器里已经多了一个没人认识的管理账户。公安部在2026年9月20日公布的网络安全行政执法10起典型案例中，第7案记录，四川宜宾某旅游开发公司的票务系统出现异常数据传输，调查发现云服务器被植入后门管理账户，数据被批量导出，而且长期未被发现。
这条通报最值得运维团队抄走的判断是：不要先问“有没有报警”，先问“陌生管理账户从哪里来、用哪个终端或密钥登录、把数据导到了哪里”。如果只查服务器是否宕机、页面是否正常，异常导出很可能继续隐藏在合法运维流量里。
通报同时写明，该公司还存在网络安全管理制度不完善、关键共用终端管理不规范、保护措施不到位，以及采集、存储、处理个人信息未履行告知义务和未采取保护措施等问题，属地公安机关已依法作出行政处罚。公开材料没有披露导出记录数量、涉及游客人数、攻击者身份和持续时长，正文不会把这些缺口补成确定事实。
先把“异常传输”拆成四段
第一段是入口。后门管理账户可能来自操作系统、数据库、云控制台、堡垒机、票务应用或第三方运维平台。不同位置的账号创建方式和日志保留范围不同，排查时不能只在服务器里搜索一个用户名。
第二段是控制。攻击者可能使用密码、密钥、会话Cookie或运维工具连接；也可能根本没创建新账号，而是滥用已有账号。判断分岔在于账号是新增、权限被修改，还是原本就存在但出现了异常来源、异常时间或异常命令。
第三段是导出。票务系统常见的敏感数据分布在业务数据库、对象存储、备份目录、日志和第三方消息队列中。批量导出还会通过应用接口、数据库客户端或云快照发生，因此只查Web访问日志往往不够。
更容易被漏掉的是“合法接口的异常调用”：攻击者不需要写出一条显眼的下载命令，只要拿着有效会话反复调用后台查询和导出功能，日志看起来仍像一名正常管理员在工作。判断时必须把调用次数、返回数据量、客户端特征和审批记录放在一起比较，而不是只看请求是否返回成功。
第四段是长期未发现。长期隐藏通常不是某个单点技术失效，而是账号盘点、关键终端管控、数据访问审计和异常外联监测没有形成闭环。它可能表现为后门账号混入共用运维账号，也可能表现为导出动作落在正常业务时间之外却没有告警。
陌生账号与合法账号被滥用，怎么分
先建一张账号对账表：把云平台的IAM用户、服务器本地账号、数据库账号、票务后台账号、堡垒机账号和API密钥放在一起，逐一核对创建时间、负责人、绑定角色、最近登录、密钥数量和权限范围。只有组织侧有人能解释其用途的账号，才能进入“合法账号”分支。
如果找到新增管理账号，继续看三类证据：一，谁在什么时间创建或提权，源IP、用户代理和调用接口是什么；二，首次登录后执行了哪些命令、打开了哪些端口、连接了哪些外部地址；三，该账号是否能绕过多因素验证或直接使用长期密钥。
如果账号原本合法，嫌疑就转向凭据滥用。此时要比较账号的常用终端、登录时段和命令基线，重点看共享终端。通报特别提到“关键共用终端管理不规范”，这意味着多人共用主机或管理终端会让账号、浏览器会话、SSH密钥和剪贴板记录难以归因，单看用户名经常无法判断是谁操作。
先封停还是先取证
顺序要按风险分岔。若账号仍在登录、正在导出，先禁用该账号、撤销会话和密钥，再保留云端与主机侧日志；不要直接删除账号或清理目录，否则会丢失创建时间、权限变更和进程痕迹。若账号已离线且系统仍在承载业务，可以先做网络隔离、快照和日志导出，再决定停机取证范围。
随后核对导出路径。数据库审计要查批量查询、全表读取、导出语句和异常客户端；对象存储要查下载、分享链接和跨区域复制；云平台审计要查快照、镜像、备份下载和密钥调用；边界与网络设备要查异常外联、长时间大流量连接和非工作时段传输。
时间线应把四个时间点分开记录：账号创建或权限变更时间、首次成功登录时间、首次批量导出时间、告警或人工发现时间。四个点之间的距离，才是判断“长期未被发现”的真实依据，而不是只看行政处罚通报里的事件月份。
四条防守行动
第一，给票务和景区系统建立“关键账户最小清单”。把云平台、数据库、服务器、堡垒机、业务后台和第三方运维平台的最高权限账号逐项列出，写明负责人、用途和复核周期。检测线索是每季度出现无法说明用途的管理账号、长期未使用的密钥或离职人员仍有效的访问权限。
第二，把共用终端改成可归因的跳板。运维人员应先登录个人身份，再通过堡垒机或短时令牌访问目标系统，禁止多人共享一个管理员账号。检测线索是同一账号在多个地理位置、多个终端指纹或多人值班表之外的时间登录。
第三，把数据导出纳入监测。数据库批量读取、对象存储下载、备份下载和应用导出接口要记录调用者、条数、目的地址和审批记录。适用于处理身份证、手机号、订单和入园记录的系统；只监控登录失败无法发现已经授权的批量导出。
第四，预设个人信息事件的报告与通知路径。发现涉及游客个人信息的异常导出后，先确认数据类别、数量和接收方，再按适用法律、合同和主管部门要求决定报告、通知与补救。通报未说明是否发生二次利用，因此处置结束前要保留“影响范围待确认”的结论，不能用“未发现”替代核查。
可保存的三问
第一问，陌生管理账户是新增、提权还是合法账号被滥用？
第二问，它在哪些时间、从哪些终端或密钥登录，向哪些数据库、存储桶和外部地址导出了数据？第三问，共用终端、云审计、数据库审计和出口流量能否拼出完整会话链，缺少哪一段证据？
三问能够回答，团队才能把“票务系统正常运行”与“账号和数据边界正常”区分开。对中小景区和票务运营方来说，最紧迫的动作不是购买更多设备，而是先确认最高权限账户和数据出口是否可解释；系统没有报错，并不等于没有人已经在后台把数据搬走。
热点来源
来源：公安部（澎湃号·政务转载），2026-09-20 08:44 北京时间，公安部公布网络安全行政执法10起典型案例，第7案：https://www.thepaper.cn/newsDetail_forward_34107823
来源：事实边界：通报确认异常数据传输、云服务器后门管理账户、数据批量导出、长期未发现及行政处罚结果；未披露数据量、游客人数、攻击者身份、持续时间和是否发生二次利用，本文不补造这些事实。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：字节脉搏实验室 tcode
tcode《票务系统没停，云服务器却多了个陌生管理账户》