聊聊关于云环境下的溯源排查

前言

人员复用就不是一个人干几个活了，是吧？

逆天发言。

啊对对对，您说的都对！

免责声明**:**

本篇文章仅用于技术交流学习和研究的目的，严禁使用文章中的技术用于非法目的和破坏，否则造成一切后果与发表本文章的作者无关。

注意：

本免责声明旨在明确指出，本文仅为技术交流、学习和研究之用，不得将文章中的技术用于任何非法目的或破坏行为。发表本文章的作者对于任何非法使用技术或对他人或系统造成的损害概不负责。

阅读和参考本文章时，您必须明确并承诺，不会利用文章中提供的技术来实施非法活动、侵犯他人的权益或对系统进行攻击。任何使用本文中的技术所导致的任何意外、损失或损害，包括但不限于数据损失、财产损失、法律责任等问题，都与发表本文章的作者无关。

本文提供的技术信息仅供学习和参考之用，不构成任何形式的担保或保证。发表本文章的作者不对技术的准确性、有效性或适用性做任何声明或保证。

  

01

**云环境下的排查
**

作为RedTeam，通常客户存在不同的环境，有的是K8S，有的是云上专网的模式，有的是域森林的模式。

你至少不能当个没得表情的攻击手吧~

今天简单聊聊云上如果被攻击了，如何排查。

02

**案例
**

场景：

客户说：我们的应用大部分都在腾讯云上，还专门买了腾讯云的安全检测服务。

这天，就在笔者准备下班run的时候，接到同事L的求助：“XX，help，云上有很多台服务器木马告警了，查了腾讯云的攻击日志，没发现攻击成功的告警的嘛~”

简单的了解了一下被控的服务器，发现不仅存在互联网的后台，还有小程序。

一边想着的时候，同事让我登录腾讯云核查一下他有没有遗漏，果然登录上去就是四台服务器执行命令的告警，我注意到四台都是root用户，先尝试性的执行whoami，ifconfig（标准的 China RedTeam 哈哈哈）。

接下来就反弹shell（python反弹，嗯，很标准，还有history），下载隧道代理工具，创建隐藏目录，安装gotohttp。

这四台服务器分别跑着不同的应用（访谈得知），并且攻击者入侵花费的时间很短，每台间隔五六分钟到半小时左右（根据某的经验来说，正常打点不太可能，要么是0day，要么运气逆天刚好找到能打的。至于扫描器，扫描器不太可能，云防护分分钟给你封了）。

翻了一下云上的攻击扫描日志，大致确定是团伙作案，扫描器扫描之后，尝试手工利用组件漏洞绕过腾讯云的WAF，但很有毅力的花了两个小时绕WAF，绕到最后一个告警也没有绕过~这是前一天的攻击告警。

命令执行的告警是出现在第二天~

看到这里，我也开始懵了。

不是哥，你漏洞都没打成功，隔了一天就入侵进来了？

先简单的梳理一下作为攻击者怎么去打云上的服务器：

1. 云上AKSK泄露

2. Web应用漏洞或者主机层面的漏洞

那么小程序呢：

小程序后端是托管在服务器上的，小程序端我们看到的实际只是JS代码。

一般出现问题的场景，硬编码了AKSK或者某些测试用的账号密码。

反过来一想：

云上的Linux服务器环境，要想符合攻击时间短（极短时间拿了四台服务器），云WAF无异常入侵成功的告警，比较符合的确实是AKSK泄露。

事后也查看了4台服务器，上面跑的web应用权限都限制了权限，并不是root用户（排除），也查看了nginx/Apache日志以及应用的异常事件日志（一开始以为0day，结果越查越不对劲）

那么接下来就两个环节：

1. AKSK怎么查是否泄露了？

2. 有没有可能是通过应用漏洞入侵？

一步一步查：

1. 既然存在web，那么果断dump JS到本地，使用正则表达式grep一下（类似的Redteam测试，这种场景并不少见）

2. 还有小程序的JS，掏出测试手机，dump受影响的服务器对应小程序的JS也dump下来grep一下。

而且这家客户也是老客户了，前两年的时候这几个站是有AKSK泄露的，正巧是笔者挖的，直接就硬编码在JS里。

想到这里，忽然想到当时web的JS确实整改了，但是小程序好像从来没看过，客户也未要求测试小程序。

果不其然，速速去查小程序，TMD，AKSK就在小程序里，并且AKSK的值并没有修改，只是删除了JS里面的AKSK而已。

总体来说，比较折腾。

03

**小结
**

事后弄了个图，算是把混乱的思路弄清晰了一点：

能查出来有些巧合，但是未知攻，焉知防呢？

有句话叫什么来着：

遇到困难不要怕，跟它刚就完了？

什么？

刚不过，不能惯着！！！

摇人，速速摇人！！！

**👇关注我了解更多安全小技巧
**