打开腾讯会议开始面试
面试官：自我介绍一下项目经历
我：20年参加某某厂商 使用了什么设备，出了什么成绩，排名是多少，捕获了一个0day，溯源到一个人。21年参加某某厂商，用来什么设备，用了什么技战法捕获了5个0day。2023年参加某某厂商，出了什么成绩。亚运会参加某某厂商，溯源成功一名攻击者等。
面试官：具体讲一下23年溯源成功的具体过程。
我：IP-whois信息-邮箱-邮箱前面一部分是ID-网络空间该ID 社交账号巡查-原籍贯住址 姓名 手机号-忘记密码得身份证后几位-身份证全号
面试官：说说webshell工具有哪些，流量特征是什么
我：
菜刀是一款远程管理工具，常用于网络攻击和渗透测试。它的流量特征主要包括：
请求头特征。在HTTP请求头中，可能会包含特定的User-Agent、Referer等信息。
请求体特征。请求体中可能存在assert eavl, base64等特征字符，并且传递的payload为base64编码。存在固定的QGluaV9zZXQo、@ini_set等字符。
数据传输方式。菜刀使用base64方式加密发送给“菜刀马”的指令，其中可能包含如z1和z2这样的关键payload名称。
冰蝎4.0:
流量特征：
1.Accept: application/json, text/javascript, /; q=0.01
2.Content-type: Application/x-www-form-urlencoded
3.冰蝎设置了10种User-Agent,每次连接shell时会随机选择一个进行使用。
4.冰蝎与webshell建立连接的同时，javaw也与目的主机建立tcp连接，每次连接使用本地端口在49700左右，每连接一次，每建立一次新的连接，端口就依次增加
5.PHP webshell 中存在固定代码
$post=Decrypt(file_get_contents(“php://input”));eval($post);
6.
冰蝎通讯默认使用长连接，避免了频繁的握手造成的资源开销。默认情况下，请求头和响应头里会带有 Connection。
Connection: Keep-Alive
7.默认时，所有冰蝎4.0 webshell都有“e45e329feb5d925b” 一串密钥。该密钥为连接密码32位md5值的前16位，默认连接密码rebeyond。
请求和响应
请求头：dFAXQV1LORcHRQtLRlwMAhwFTAg/M
解密后：@error_reporting(0);\r
响应头：TxcWR1NNExZAD0ZaAWMIPAZjH1BFBFtHThcJSlUXWEd
解密后：{“status”:”c3VjY2Vzcw==”,”msg”:”
其中”c3VjY2Vzcw==”经过base64解密后的内容为success
哥斯拉：
1.User-Agent (弱特征)
哥斯拉客户端使用JAVA语言编写，在默认的情况下，如果不修改User-Agent，User-Agent会类似于Java/1.8.0_121（具体什么版本取决于JDK环境版本）。但是哥斯拉支持自定义HTTP头部，这个默认特征是可以很容易去除的。
2.Accept（弱特征）
Accept为text/html, image/gif, image/jpeg, *; q=.2, /; q=.2对这个默认特征应该很熟悉了，之前冰蝎也出现过同样的Accept。为什么会这么巧合出现两个工具都会出现这个特征呢，其实这个也是JDK引入的一个特征，并不是作者自定义的Accept（参考：Loading…）。同样的这个默认特征也可以通过自定义头部去除，只能作为默认情况下的辅助检测特征。
3.Cookie (强特征)
哥斯拉的作者应该还没有意识到，在请求包的Cookie中有一个非常致命的特征，最后的分号。标准的HTTP请求中最后一个Cookie的值是不应该出现;的，这个可以作为现阶段的一个辅助识别特征。后面如果作者意识到这个问题的话应该会发布新版本修复这个问题。
4.请求体特征 (较强特征)
因为无法准确识别加密的请求体，所以只能采用比较宽泛的匹配条件去匹配请求体特征，宽泛的匹配思路其实就是基于区别大部分正常的数据包，加密数据包自身体现的特征。这种宽泛的匹配在一些情况下可能会带来误报，因此有时候难以作为一种非常有效的检测手法。
哥斯拉支持对加密的数据进行base64编码以及原始的加密raw两种形式的通讯数据，对于请求体的检测也要考虑两种情况。首先看一下base64编码的数据包，对于这种数据包唯一的识别方法就是识别流量中的base64编码。当然不能仅仅去识别数据包中存在base64编码就拦截，因为很多应用正常的参数也会采用base64编码加密。哥斯拉在进行初始化时会产生一个比较大的数据包，后面进行命令执行等操作时产生的base64数据包会比较比较小。在长度上做一个匹配条件在一定程度上也可以降低误报率。
对于原始加密raw请求体，没想到比较好的方法，目前只想到到了匹配较多的不可见字符的思路。同样的，这种检测方法也会产生误报，像一些对传输安全要求比较高的金融机构，不少应用也会实现一些加密的通讯流量。需要注意的是，在匹配不可见字符时，需要排除文件上传，也就是multipart/form-data数据包，因为文件上传的流量也会包含大量的不可见字符。
5.响应体特征 (强特征)
和请求体一样，请求响应体也分两个格式，base64编码的和原始加密raw数据。如果请求体采用base64编码，响应体返回的也是base64编码的数据。在使用base64编码时，响应体会出现一个很明显的固定特征。这个特征是客户端和服务端编写的时候引入的。
从代码可以看到会把一个32位的md5字符串按照一半拆分，分别放在base64编码的数据的前后两部分。整个响应包的结构体征为：md5前十六位+base64+md5后十六位。从响应数据包可以明显看到这个特征，检测时匹配这个特征可以达到比较高的检出率，同时也只可以结合前面的一些弱特征进行检查，进一步提高检出率。因为md5的字符集范围在只落在0123456789ABCDEF范围内，因此很容易去匹配，正则匹配类似于(?i:[0-9A-F]{16})[\w+/]{4,}=?=?(?i:[0-9A-F]{16})。需要注意的是md5需要同时匹配字母大小写两种情况，因为在JAVA版webshell响应中为大写字母，在PHP版中为小写字母。编写对应检测规则，在ModSecurity上测试成功拦截。
但是比较遗憾的是对于原始加密数据的raw形式响应包并没有比较好的检测思路，只能和请求体检测一样，匹配不可见字符。
面试官：shir550 721的原理和区别
我：shiro550记住密码处 字段 序列化 加密aes加密 base64加密 ，服务端则是相反，密钥是硬编码，很容易得到，721则不是，需要爆破出来，时间很久，一般在活动中不用。
