起因
晚上登录我的网站后台管理面板时发现日志记录中的用户名不对劲
用户名为[]，再次刷新后，强制下线了我的登录状态
再次登录后发现网站在请求ezxss.net
然后登录日志被删了
处理过程
急忙上服务器查看网络连接情况，然而并没有什么异常链接
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:15329 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:8899 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:17380 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:17221 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:4200 0.0.0.0:* LISTEN 9630/ng serve
tcp 0 0 127.0.0.1:17033 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:17131 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:81 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:82 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:15538 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:15445 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:9080 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:15640 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:17400 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:7033 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:8090 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:52030 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:42308 127.0.0.1:8090 ESTABLISHED -
tcp 0 0 10.0.24.4:41444 109.244.198.9:9988 ESTABLISHED -
tcp 0 0 127.0.0.1:8090 127.0.0.1:42308 ESTABLISHED -
tcp 0 0 10.0.24.4:45274 169.254.0.138:8186 ESTABLISHED -
tcp 0 0 127.0.0.1:8090 127.0.0.1:49718 CLOSE_WAIT -
tcp 0 0 10.0.24.4:47644 10.0.24.4:8090 TIME_WAIT -
tcp 0 3236 10.0.24.4:22 我自己的ip:4284 ESTABLISHED -
tcp6 0 0 :::3306 :::* LISTEN -
tcp6 0 0 :::111 :::* LISTEN -
tcp6 0 0 :::52030 :::* LISTEN -
udp 0 0 127.0.0.53:53 0.0.0.0:* -
udp 0 0 10.0.24.4:68 0.0.0.0:* -
udp 0 0 0.0.0.0:111 0.0.0.0:* -
udp 0 0 10.0.24.4:123 0.0.0.0:* -
udp 0 0 127.0.0.1:123 0.0.0.0:* -
udp 0 0 0.0.0.0:852 0.0.0.0:* -
udp6 0 0 :::111 :::* -
udp6 0 0 ::123 :::* -
udp6 0 0 ::1:123 :::* -
udp6 0 0 :::852 :::* -
这个109.244.198.9不知道哪里的地址，先使用iptables禁止他联网
iptables -A OUTPUT -d 109.244.198.9 -j REJECT
查询面板论坛后发现有多个用户提到自己服务器发现恶意木马文件以及被云服务提供商告警存在木马病毒
在我自己服务器上排查后同样发现此问题
时间可以追溯到1月了，可怕！！！
对nginx log日志进行分析后只是找到了部分恶意扫描的ip
47.101.149.21
183.136.225.32
等等
喊了大哥对恶意文件进行分析发现木马中存在外联ip
使用ti平台对ip进行分析，猜测攻击者可能就是这个ip,至于这么多面板环境,可能是自己搭建测试的漏洞环境
这里然后把自己的业务代码备份后，重装服务器
排查
捕获攻击者
接着使用docker搭建了该系统环境，发现其生成的后台路径和之前的一样，这里可能是该面板的设计问题
既然之前发现用户名为[]这种，那自己插一下试试，结果还真成功了，那就是xss漏洞导致的
<img src=1 onerror=alert(1)>
那么就让他跑几天
正向思维-替换恶意文件
在docker中经过几天的运行，再一次登录进docker环境，先把所有相关的文件进行备份，然后通过之前的对文件进行监控以及对代码的分析
发现该系统的所有数据存在于libc.so.1.0.1文件中，可以使用如下命令对目录进行监控
apt install inotify-tools
inotifywait -m -r -e modify,delete,create,attrib path
之后只需要将此已被写入后门的文件替换新环境的就可以恢复到问题环境
问题再现
登录系统后台，同样也中了，并且系统正在进行挖矿
面板日志同样被删除了，gg
1day捕获
这里想了想，在面板删除前他应该是需要执行加载js的，所以肯定是我登录后触发，那么他肯定会有这个xss的文件
再次恢复问题环境后，直接用burp进行抓包，查看log日志的接口数据，果然发现加载的js文件
访问一下，这不就拿到day了
后续思考
1.他是怎么知道我后台地址的？可能原因：经过我之前的多次重装，发现后台地址都一样，这里肯定是有一定的生成规则的，不会逆向，看不懂了
