Kinsing攻击剖析:一个开放的PostgreSQL端口如何让我的AWS服务器暴露了7天

admin 2026-02-03 00:54:25 网络安全文章 来源:ZONE.CI 全球网 0 阅读模式

文章总结: 文档剖析了一起因PostgreSQL端口暴露导致的AWSEC2实例遭Kinsing恶意软件入侵事件。攻击者利用COPYFROMPROGRAM实现远程代码执行,并通过无文件攻击、进程伪装及DoH通信持久化控制。建议采用ZeroTrust架构,关闭公网端口,使用SSH隧道并加强实时监控以防御此类配置疏忽威胁。 综合评分: 88 文章分类: 应急响应,恶意软件,漏洞分析,云安全,实战经验


cover_image

Kinsing 攻击剖析:一个开放的 PostgreSQL 端口如何让我的 AWS 服务器暴露了 7 天

haidragon haidragon

安全狗的自我修养

2026年2月2日 11:56 湖南

官网:http://securitytech.cc

事件概览

  • 事件:一台普通的 AWS EC2 实例被入侵,并被加入 Kinsing 僵尸网络,持续 7 天。
  • 原因:开发期间遗忘的“临时”规则 —— PostgreSQL 5432 端口对 0.0.0.0/0 开放
  • 攻击方式:攻击者通过 COPY FROM PROGRAM 实现 UDF 远程代码执行(RCE) 并投放恶意载荷。
  • 恶意软件Kinsing,具备 无文件执行DoHTor 路由 C2 等能力。
  • 修复:迁移到 Zero Trust 架构,关闭公网 DB 端口,使用 SSH 隧道,并增加实时连接告警。

引言

在云管理世界里,功能性与漏洞之间只有一线之隔。一个为了方便数据库访问的快速配置,几分钟内就可能成为全球僵尸网络的入口。

这是真实发生在 AWS EC2 上的事件:一个暴露的 PostgreSQL 5432 端口,使得一次高级入侵在服务器中潜伏了一整周而未被发现。

事件来自 AWS Trust & Safety 的滥用报告。取证发现攻击者部署了 Kinsing 恶意程序,它不仅利用了 RCE,还结合了 DNS over HTTPSTor 通信 以及直接在内存中执行的“无文件”技术来绕过检测。


第一部分:AWS 通知

事情发生在 us-east-1 区域的一台 EC2 实例 上,运行 PostgreSQL 16.11,表面上环境很正常。

触发点:没人想收到的邮件

不是 CPU 报警,也不是宕机,而是来自 AWS Trust & Safety 的邮件:

实例存在对第三方的滥用行为。

AWS 检测到实例存在异常外联流量,说明服务器已被劫持。

现实:被潜伏 7 天

取证后发现这不是一次简单攻击,而是持续控制。


第二部分:0.0.0.0/0 的陷阱

真正的入口不是 0day,而是 Security Group 的配置错误

漏洞:PostgreSQL 5432

开发时临时把 5432 设置为:

0.0.0.0/0

结果这个“临时”变成了永久后门。


利用方式:RCE

端口被扫描发现后,攻击者使用 PostgreSQL UDF RCE

利用:

COPYFROM PROGRAM

直接在 Ubuntu 上执行系统命令。

  • 初始载荷:下载器连接 C2
  • 权限利用:使用 postgres 用户创建进程
  • 伪装进程名systemd-tmpfiles-cleanup

第三部分:识别 Kinsing

日志显示来自多个国家扫描 5432。


关键 Hash

在 /tmp 和 /dev/shm 中找到二进制文件。

SHA256:

5e8b5c2fc77c0a5a437c154a34cdb1c18ee6fe29ee209ec4385184ff03e83755

VirusTotal 结果:

确认是 Kinsing / CoinMiner


高级规避技术

  • 无文件执行:只在内存中运行

  • DoH 通信
  • 日志膨胀攻击


Kinsing 持久化方式(MITRE)

1. 计划任务持久化 T1053

每小时 25 分执行,自动复活。


2. 进程伪装 T1543

伪装为:

systemd-tmpfiles-cleanup

3. 防御规避 T1027 / T1070

  • 杀死其他矿机
  • Base64 + pipe 执行

4. C2 通信 T1071 / T1571

  • DoH
  • Tor Socks
  • .onion C2

深度分析 Dropper

  • 指纹收集
  • DoH + Tor
  • /dev/shm 无文件执行
  • watchdog 自愈

(原始脚本保持不变)

[脚本原文略…]

修复与加固:Zero Trust


1. 紧急处置

  • 停止实例
  • 删除 0.0.0.0/0
  • 清理 cron / tmp

2. Zero Trust 重构

  • PostgreSQL 仅监听 localhost
  • SSH Tunnel 访问
  • SCRAM-SHA-256

3. 监控与告警

  • log_connections
  • 固定 IP 白名单
  • Python 告警

结论

Kinsing 利用的不是高端漏洞,而是管理员的一个小疏忽。

在云环境中:

安全不是功能,而是基础设施本身。

  • 公众号:安全狗的自我修养
  • vx:2207344074
  • http://gitee.com/haidragon
  • http://github.com/haidragon
  • bilibili:haidragonx

#


免责声明:

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。

任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我

本文转载自:安全狗的自我修养 haidragon haidragon《Kinsing 攻击剖析:一个开放的 PostgreSQL 端口如何让我的 AWS 服务器暴露了 7 天》

评论:0   参与:  0