文章总结： 香港医管局于2026年4月3日发现涉及九龙东医院联网5.6万名病人的数据外泄事件，数据已于4月2日在暗网论坛darkforums.su被泄露团伙LulzIntel发布。外泄数据源自承办商的下游同步数据库，包含诊断、病房、科室等高敏感字段，远超官方披露范围。研判认为泄露动机以提升江湖声誉为目的，医管局内部网络与数据流出环节缺乏有效的实时监控覆盖。
综合评分： 85
文章分类： 数据泄露,供应链安全,安全运营,漏洞分析,应急响应
香港医管局 56,000 名病人数据外泄事件溯源与影响评估
原创
独眼情报
独眼情报
独眼情报
2026年4月7日 12:30
湖北
- 涉事范围：九龙东医院联网
- 外泄平台：darkforums
2026 年 4 月 3 日凌晨二时许，香港医院管理局（下称医管局，HA）的恒常监察系统发现一宗未经授权的病人资料外泄事件，涉及九龙东医院联网（Kowloon East Cluster, KEC）超过 56,000 名病人。数据于 4 月 2 日已在暗网论坛 darkforums.su 上以化名 Demetrius 发布，发帖人宣称归属于一个名为 Lulzintel 的小型泄露团伙。
医管局对外口径强调「事件不涉及网络攻击」，并已即时暂停涉事承办商的系统维护工作。香港个人资料私隐专员公署（PCPD）与警方网络安全及科技罪案调查科已介入。
外泄数据库的 lookup 表结构提供了远比官方声明更详尽的字段图景：除官方披露的姓名、性别、HKID、医院档案号码、手术内容外，还包含诊断（Diagnosis）、病房（Ward）、科室（Dept）、预约编号（ApptNo）、预定手术日期（ScheduleOTDate）等高敏感字段。其中诊断字段在医管局公告中完全没有提及。
核心研判（中等置信度）：
- 研判：本次事件几乎可以确定源自承办商侧的一个下游同步数据库，而非对医管局核心 HIS（医院信息系统）的直接入侵。 表名为
lookup、引擎为已被业界淘汰的 MyISAM、字符集为非现代标准的 utf8，加上三个不同名的同步时间戳字段（HISUpdateTime / RecordSyncTime / mySQLSyncTime），共同指向一个由承办商搭建、从医管局核心 HIS 拉取数据的「便捷查询/手术调度辅助系统」。 - 研判：医管局的公开口径存在选择性披露。 实际外泄字段包含诊断、科室、病房等内容，比官方公告的「姓名、性别、HKID、档案号、手术内容」更敏感、更具体。
- 研判：泄露动机以「江湖声誉」为主、商业牟利为辅。 Lulzintel 在 2026 年 1 月以来已多次在 BreachForums 与 darkforums 上免费投放数据集，本次发帖未见公开标价，与典型的勒索运营模式不符。
整体置信度：中。事实层证据充分；归因层（具体哪一家承办商、Lulzintel 的真实身份）证据严重不足。
一、事件背景与时间线
九龙东医院联网是医管局七大区域联网之一，覆盖联合医院、将军澳医院与灵实医院等设施，年服务量以百万计。本次外泄虽未涉及核心电子病历系统的全量数据，但 5.6 万条「带诊断与手术内容」的结构化记录，在医疗信息泄露语境下属于极高价值数据。
| 时间（UTC+8） | 事件 | 信源 |
| — | — | — |
| 2026-04-02 | 化名 Demetrius 在 darkforums 创建帖子，发布 ha.org.hk 数据集 | DarknetSearch（Apr 3 报道） |
| 2026-04-03 约 02:00 | 医管局恒常监察系统侦测到「未经授权将病人资料取走并于第三方平台外泄」 | 医管局官方声明 |
| 2026-04-03 上午 | 医管局向警方及私隐专员公署通报 | 医管局官方声明 |
| 2026-04-03 全日 | 医管局即时暂停承办商系统维护工作 | South China Morning Post |
| 2026-04-04 14:58 | 医管局通过新闻公报对外披露事件 | info.gov.hk |
| 2026-04-04 全日 | 九龙东医院联网热线 5215 7326 启用 | 医管局官方声明 |
| 2026-04-06 | 前九龙东医院联网行政总监陆志聪在电台节目就事件发声 | The Standard |
时间线关键观察：从 darkforums 发帖（4 月 2 日）到医管局自身侦测（4 月 3 日凌晨），存在大约 24 小时的「外部已知、内部未知」窗口期。医管局的「监察系统」更可能是事后型的暗网监测或外部情报馈送，而非实时拦截的内部 DLP 工具。研判：医管局是被动获悉数据已被外发，而不是主动拦截到入侵动作——这意味着内部网络与数据流出环节缺乏有效的实时监控覆盖。
二、外泄数据的字段构成与敏感度评估
2.1 完整字段清单
根据外泄数据库的 lookup 表结构，每条记录包含的字段如下：
| 字段名 | 类型 | 含义 | 是否在医管局官方公告中提及 |
| — | — | — | — |
| id | int(11) | 主键 | — |
| ApptNo | varchar(20) | 预约编号 | 否 |
| HN | varchar(20) | 医院档案号码（Hospital Number） | 是 |
| HKID | varchar(20) NOT NULL | 香港身份证号码 | 是 |
| LastName / FirstName | varchar(60) | 姓名（拆分两列） | 是（合并为「姓名」） |
| DoB | datetime | 出生日期 | 部分（被 SCMP 等媒体补充提及） |
| Gender | varchar(50) | 性别 | 是 |
| Procedure | varchar(256) | 手术内容 | 是 |
| Diagnosis | varchar(256) | 诊断结果 | 否 ⚠️ |
| EmEl | varchar(50) | 推测为 Emergency Eligibility（医管局急症收费类别）或 Emergency Level | 否 |
| Ward | varchar(200) | 病房 | 否 |
| Dept | varchar(200) | 科室 | 否 |
| ScheduleOTDate | datetime | 预定手术日期（Scheduled OT Date） | 否 |
| HISUpdateTime | datetime NOT NULL | 上游 HIS 系统的记录最后更新时间 | — |
| RecordSyncTime | datetime NOT NULL | 中间层同步时间 | — |
| InternalPatientID | int(10) NOT NULL | 内部病人 ID | — |
| PatientIndex | int(10) NOT NULL | 病人索引 | — |
| mySQLSyncTime | timestamp | 本地 MySQL 同步时间 | — |
2.2 公告与现实之间的字段差距
将上表与医管局 4 月 4 日新闻公报的措辞——「病人姓名、性别、身份证号码、医院档案号码和手术内容等资料」——做对照，至少有四组高敏感字段被官方公告完全跳过：
- 诊断（Diagnosis）：256 字符的自由文本字段，足以容纳具体疾病名称与临床描述
- 病房与科室（Ward / Dept）：直接揭示病人所在的临床场景，例如肿瘤科、精神科、产科等
- 预定手术日期（ScheduleOTDate）：将病人定位到具体的某一天某一台手术
- 预约编号（ApptNo）：可能涉及医管局内部预约系统的全局编号空间
医管局公告末尾使用了「等资料」一词作为兜底，但研判：在官方披露中省略「诊断」与「科室」这两个字段，要么是出于公关压力下的「最小化披露」策略，要么是公告执笔者本身尚未掌握完整的字段清单。无论哪种解释，都意味着实际伤害面比公告读者所感知的更宽。
2.3 字段背后揭示的系统架构
lookup 表结构里有四个非常关键的技术细节。
第一，表名是 lookup。在数据库命名习惯里，名为 lookup、cache、search、view 之类的表，几乎总是「为了某个具体业务场景而预先聚合好的查询表」，而不是事务型核心表。它的存在本身就说明：上游有一个更完整的核心系统，下游有一个为方便查询而存在的派生副本。
第二，三个互不相同的同步时间戳字段：HISUpdateTime、RecordSyncTime、mySQLSyncTime。这是一条三段式的数据同步链路——数据从上游的 HIS（医院信息系统，医管局核心系统）出发，经过某个中间层（产生 RecordSyncTime），最终落地到本地的 MySQL 实例（产生 mySQLSyncTime）。这种「拉取-中转-落地」的三段架构，是典型的「承办商在自己机房或云上部署一份只读副本、供自家应用查询」的模式。
第三，ENGINE=MyISAM、CHARSET=utf8。这两个选项放在 2026 年的医疗系统语境下，是非常刺眼的技术信号。MyISAM 自 MySQL 5.5（2010 年）起就被 InnoDB 取代为默认引擎，它不支持事务、不支持外键、行级锁缺失，长期被任何严肃数据库工程师视为「禁用项」；utf8 在 MySQL 内是个 3 字节实现，连完整的 CJK 扩展字符与 emoji 都无法存储，正确的现代默认值应该是 utf8mb4。一个为医疗数据服务的系统在 2026 年仍然采用 MyISAM + utf8，研判：要么这套系统是十年前的遗留产物从未被现代化，要么是某个低成本承办商以最快速度搭出来的「能跑就行」战术工具，从未经过严肃的数据库工程评审。两种可能都指向同一个结论——这套承载病人数据的下游系统在工程严肃度上远低于医管局核心 HIS 应有的标准。
第四，ScheduleOTDate 字段配合 lookup 表名，强烈暗示这是一套手术调度或术前查询辅助工具。在临床工作流里，需要一份「按 HKID 或 HN 快速查到病人姓名、诊断、手术、病房、预定手术日期」的便捷查询表的，最典型场景就是手术室协调、术前核对、麻醉评估等场景。这类工具往往由临床部门提需求、外包给承办商小团队快速开发，技术债极重，安全治理最薄弱。
把这四个观察拼起来：研判：本次外泄的源头几乎可以确定不是医管局的核心 HIS，而是某家承办商为九龙东医院联网搭建的、用于手术或诊疗调度协助的下游同步数据库。这一研判将在第四章与入侵向量分析结合，进一步收敛到具体假设。
三、对手画像：Lulzintel 与 Demetrius
3.1 已知作案历史
事实层（L1）：
- 帖子作者使用化名 Demetrius，归属团伙名 Lulzintel（来源：DarknetSearch）。
- 2026 年 1 月 5 日左右，Lulzintel 在 BreachForums 发布巴西电商平台 Mist Store 的数据库泄露贴，宣称包含约 30,000 笔订单（来源：DarkWebInformer）。
- 2026 年 1 月 14 日，Lulzintel 宣称对伊朗加密货币交易所 Almaex 造成数据泄露，涉及超过 50,000 条用户记录（来源：DarkWebInformer / Hendry Adrian）。
- 2026 年 3 月初，韩国威胁情报厂商 S2W 在其每周暗网通讯中记录了 Lulzintel 公布约 33,000 条某政党成员记录的事件。
3.2 画像研判
研判：Lulzintel 是一个机会主义型、跨地理目标的小型泄露集合，主要追求论坛声誉积分而非直接经济收益。 依据有三：
第一，目标横跨巴西电商、伊朗交易所、东亚政党与香港医疗，缺乏行业聚焦或地缘聚焦，这是「机会主义猎物」典型模式。
第二，过往帖子均以发布或免费投放为主，未见持续性勒索运营基础设施（专属泄露站、Tor 镜像、付款入口等）。
第三，团伙名 Lulzintel 本身致敬的是更早一代的 LulzSec 文化——lulz（嬉笑）+ intel（情报），命名风格高度暗示「为了好玩」而非「为了营生」。
反向假设：也可能 Lulzintel 是某更大规模犯罪生态（例如借壳 ShinyHunters / The Com 圈层的 access broker）的前置发布马甲，用免费投放制造话题、为后续付费数据交易引流。这一假设目前的证据弱在：尚未观察到 Lulzintel 帖子向任何付费渠道导流的链路。
待证实：Demetrius 与 Lulzintel 的关系是「同一人不同身份」、还是「团伙下的发帖代理」、抑或「两者本无关联，发帖者借 Lulzintel 名号蹭热度」。在 darkforums 这种身份准入极弱的平台上，化名借用是常态。
3.3 与本次事件的匹配度
把 Lulzintel 的过往画像套到本次事件上，匹配度相当高：
- 目标选择：一个面向公众的政府机构子系统，符合「易被外部扫描发现的猎物」特征；
- 数据规模：5.6 万条，与其过往的 3 万至 5 万级单笔投放规模一致；
- 投放方式：免费上传，未公开标价，符合声誉驱动模式；
- 披露平台：darkforums.su 而非自有泄露站，符合「借平台流量、不投入运营成本」的小团伙习惯。
但需要警惕的是：高匹配度本身并不构成归因证据。任何熟悉 Lulzintel 公开模式的模仿者都可以复制这些特征。
四、入侵向量研判
4.1 医管局口径的拆解
医管局的官方表态有两个值得拆解的点：一是它强调「事件不涉及网络攻击等因素」；二是它「即时暂停承办商的系统维护工作」。把这两句话放在一起读，医管局事实上已经把矛头指向承办商侧，但又用「无网络攻击」一句话兜住了医管局自身核心系统的清白叙事。
香港信息安全研究员赖灼东（Anthony Lai Cheuk-tung）在接受本地媒体采访时直接称这一表态是「烟雾弹」。他指出，黑客经常监控为本港机构服务的承办商，并伺机利用其漏洞窃取数据，即便不直接攻入主机构网络。「原始档案」通常在维护、备份或测试期间由承办商批量导出，事件极有可能源于承办商一侧的导出文件被人下载——调查重点应在于该文件在承办商服务器上是否得到妥善保护，以及是谁下载了它。
前九龙东医院联网行政总监陆志聪（Luk Che-chung）也在电台节目中给出了一个内行视角的关键质疑：医管局的内部访问控制原则是「与该病人当前临床责任挂钩」，员工无法随便下载档案，因此 5.6 万条「原始档案」级别的批量外泄非常异常，应当聚焦调查来源是内鬼还是承办商。
4.2 schema 提供的强化证据
外泄数据库的 lookup 表结构对入侵向量研判提供了远比官方口径更直接的证据。
HISUpdateTime 字段是关键证物。这个字段专门用来存储「上游 HIS 记录的最后更新时间」，意味着这套被泄系统在数据流向上明确处于 HIS 的下游——它的数据是从医管局核心 HIS「拉过来」的，而不是它自己产生的。配合 RecordSyncTime 与 mySQLSyncTime，可以重建出一条三段式数据流：
医管局核心 HIS → 中间同步层 → 承办商本地 MySQL（被泄出处）
↑ ↑ ↑
HISUpdateTime RecordSyncTime mySQLSyncTime
这条数据流意味着两件事：
第一，外泄事件不需要、也不太可能涉及对医管局核心 HIS 的直接入侵。攻击者只需要拿到链路最末端那台承办商 MySQL 的访问权限，就能拿到 5.6 万条已经从 HIS 拉好、聚合好、扁平化好的现成结构化数据。从攻击经济学角度，这是难度最低、收益最高的攻击面。
第二，医管局「不涉及网络攻击」的口径在字面上可能是真的——指的是医管局自己的核心网络与 HIS 没有被入侵——但在普通公众的理解里这一表述具有严重误导性。事件的发生地点不是医管局的网络，但事件的责任主体仍然是医管局对承办商的管控。
MyISAM + utf8 的工程信号进一步压缩了攻击门槛。一个用 MyISAM 引擎运行的 MySQL 实例在 2026 年的安全语境下基本意味着：缺少现代访问控制设计、可能跑在一台老旧的 Linux/Windows 服务器上、补丁与监控可能都不到位、密码与凭证管理可能仍停留在 10 年前的水平。攻击者面对这样的目标，可选的入侵路径多到难以列举——SQL 注入、暴露的 phpMyAdmin、弱口令的 SSH、未打补丁的 Web 应用、或者干脆是某个公开 GitHub 仓库里被遗忘的连接字符串。
4.3 三种入侵向量假设
基于以上事实，可以构建三种入侵向量假设，并按当前证据给出置信度排序：
| 假设 | 描述 | 当前置信度 | 缺失证据 |
| — | — | — | — |
| H1 承办商的下游应用被外部入侵 | 攻击者通过 Web 漏洞、暴露端口、弱口令或承办商基础设施漏洞，获取了那台 MyISAM 数据库的访问权限并导出全表 | 高 | 承办商身份、具体入侵路径、初始访问时间点 |
| H2 承办商内部人主动外发 | 承办商内部员工出于谋利、报复或意识形态动机，将自家系统中的数据库主动导出并外发 | 中 | 数据交易记录、承办商内部审计日志 |
| H3 医管局内部人员越权下载 | 医管局内部具备访问权限的员工借机批量导出 | 极低 | 与「即时暂停承办商作业」直接矛盾，且外泄数据呈现为承办商下游表结构而非 HIS 原生格式 |
H1 在 schema 证据出现后，置信度从「中高」提升到「高」。理由是：
第一，外泄数据的格式特征（lookup 表名、MyISAM 引擎、三段式同步时间戳）与「攻击者从核心 HIS 直接拖库」的场景完全不符——HIS 一般是大型商业 EHR 系统，不会把数据存在 MyISAM 表里，更不会用 lookup 这种命名。
第二，这套架构的薄弱程度使得外部入侵几乎是必然结果而不是偶然事件——一台跑着 MyISAM 的 MySQL，如果暴露在互联网或承办商内网薄弱区，被攻陷的时间窗口只是「几天还是几周」的问题。
第三，Lulzintel 的过往作案模式（巴西电商、伊朗交易所、政党网站）几乎全部以外部 web 应用层入侵为主，与「内部勾结」模式不符。
H3 几乎可以排除。如果是医管局内部人员从核心 HIS 越权下载，外泄数据的格式应该接近 HIS 原生表结构，而不会出现 mySQLSyncTime、PatientIndex 这种典型的「下游同步副本」字段。
4.4 反向假设
反向假设：医管局「无网络攻击」的判断是否可能被推翻？
如果未来出现以下任一证据，则需要把入侵向量重新归零：
- 承办商或医管局的边界设备日志显示了从承办商网络回流到 HIS 的未授权访问；
- 外泄数据集中出现了 HIS 原生表结构的字段或元数据（这会推翻「下游副本被泄」假设）；
- Lulzintel 在论坛中追加披露入侵细节并展示其曾访问过医管局核心系统的证据。
截至本文成稿时，三项均未观察到。基于现有证据，「核心 HIS 安全」与「承办商系统被攻陷」这两个判断可以同时成立，而且这正是最可能的真实情况。
五、外泄平台 darkforums 的角色与可信度
darkforums是 BreachForums 在 2025 年遭执法行动重创之后崛起的主要替代平台之一。根据 KELA 与 SiliconANGLE 的报告，该论坛在 2025 年 4 月至 6 月之间用户基数增长约 600%，承接了大量从 BreachForums 流出的卖家与买家。其管理层经历了从 Lucifer 到 Knox（疑似来自印度尼西亚）的交接。
darkforums 在 2025 年 7 月还经历过自身被攻击的事件——一名自称 test55 的攻击者通过 SSRF 漏洞展示了对论坛的渗透。这一点对本次分析有间接意义：研判：darkforums 平台本身的运营安全水位并不高，这导致投放在其上的数据集被多重监测、抓取和传播的概率极高。一旦数据落入 darkforums，其后续扩散是几乎不可逆的——再删帖也无济于事，因为情报厂商、记者、其他犯罪团伙会在数小时内完成镜像与转载。
对香港医管局而言，这意味着哪怕警方迅速联系平台运营方要求下架，外泄数据的传播控制窗口在事实上早已关闭。后续的工作重心应该从「阻止扩散」转向「追踪利用、保护受害人」。
值得一提的是，发帖人 Demetrius 选择 darkforums 而非更隐秘的 Tor 私聊频道或加密通讯渠道，本身就传递了一个信号：他要的是公开曝光与论坛声誉，而不是私下交易。这与第三章对 Lulzintel 整体动机的画像相互印证。
六、影响评估
6.1 对受影响病人的直接影响
对 56,000 余名九龙东联网病人而言，最现实的风险有四类。
钓鱼与冒名医务沟通。攻击者掌握了姓名、HKID、医院档案号码、诊断、科室、病房与预定手术日期之后，可以构造极其逼真的「医院随访电话」「术后保险理赔通知」「复诊提醒」等社工剧本。由于剧本内容与受害人真实就诊经历完全吻合——细到某月某日在某科某病房做某手术——常规的「不轻信陌生来电」教育在这种情境下几乎无效。诊断字段的存在尤其加重了这一风险，因为攻击者可以在电话开场就准确说出对方的病情，瞬间击穿心理防线。
身份盗用与金融诈骗。HKID 是香港金融、政务、电讯账户开立的身份核心。在已掌握 DOB 与全名的前提下，攻击者可以尝试电话绕过、SIM swap、低门槛账户开立等动作。相较加密货币交易所或电商平台的密码泄露，HKID 泄露的危害更慢热但更深远——HKID 是终身唯一的标识符，受害人无法像更换密码一样去「更换」自己的身份证号。
敏感病史的隐性歧视。Diagnosis 与 Procedure 两个字段一旦在小范围圈子内被检索，可能影响劳务市场（求职背景调查）、商业保险（核保与拒保）、人际关系（家庭与社交）等多重维度。这部分危害最难量化，也最难追溯。
针对性勒索与骚扰。对于涉及隐私敏感诊断的病人（如终止妊娠、HIV 相关、肿瘤、整形、精神科），存在被针对性勒索或暴露威胁的可能。Ward 与 Dept 字段进一步强化了这一风险——精神科病房、肿瘤科病房、性健康诊所等敏感科室的标签直接暴露在数据集中，使得「按科室筛选高价值受害人」这种攻击手法在技术上完全可行。
6.2 对医管局与香港医疗系统的中期影响
研判：本次事件大概率会成为推动香港医疗机构第三方风险管理立法或监管规则升级的导火索。 香港私隐专员公署近年已经数次就政府机构外泄事件发出执法通告，但针对承办商生态的强制性合规框架仍相对宽松。陆志聪与赖灼东在媒体上的发声方向高度一致——他们都把矛头指向承办商监督，并提出「跳板服务器（jump server）」式的中间监控层应该成为政府部门的强制配置。这类专家声音对监管侧议程设定具有较强的导向作用。
短期内，可以预期医管局会启动一轮覆盖所有现役承办商的访问凭证轮换、最小权限审计与维护日志倒查。但研判：这类事后审计的根本局限在于——它只能发现「已经发生的越权」，无法解决「合法权限下被授权拷贝出来的数据散落在承办商机房」的结构性问题。本次事件最深的教训其实是：医管局对「数据离开 HIS 之后流向哪里」这件事，缺乏全链路的可见性。一份从核心 HIS 同步出去的副本，落地到了一台跑着 MyISAM 的承办商 MySQL 上，这个事实本身就不应该发生在 2026 年的医疗信息系统治理中。
6.3 对香港数据治理框架的次生影响
香港的《个人资料（私隐）条例》在 2021 年针对「起底」行为做过重大修订，但在数据外泄的强制披露义务上仍属偏宽松的体制——目前并无法定的 72 小时通报窗口。本次事件中，医管局从内部侦测到对外披露的间隔约 36 小时，按本地标准已属及时，但相比 GDPR 体系仍有明显差距。
更值得关注的是「披露完整度」而非「披露时效」。医管局公告中省略了诊断、科室、病房等高敏感字段的存在，而这些字段恰恰是受影响病人评估自身风险时最需要知道的信息。研判：本次事件可能引发关于「数据外泄披露应当列明完整字段清单」的讨论——这是比单纯的披露时限更基础的合规要求，但目前在香港监管框架中并未被明文强制。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：独眼情报 独眼情报
独眼情报《香港医管局 56,000 名病人数据外泄事件溯源与影响评估》