Empire从上线到现在,已经在渗透方面有了很广泛的应用。我们所见到有关Empire的大多数文章都是它的使用手册,都是前面介绍如何安装,后面再带一些相同的话,这样的文章没什么实际的意义。
本文将通过一个模拟的案例向大家展示从初次访问到最终的权限获得,让大家深刻的体会Empire的强大功能。在这个链接里有实际的案例: https://www.youtube.com/watch?v=xHkRhRo3l8o
初次访问
Empire有多种不同的方式来把stager模块加载到主要的代理中运行,包括Office宏命令,war文件,HTAs,etc。 在以后的博客中,我们将重点讲钓鱼网络,但是现在,我们先假定我们已经通过一个Office宏命令得到了进入企业的环境的权限。在本篇文章里,我们把重点放在“DEV”域中的个人工作站,这个域是“CORP”域的一个子域。
提升权限
首先,通过查看主要的代理菜单—其中,带有(*)的是已被提升过的代理。我们应该注意到的是我们的账号并没有提升权限, 当然也可以直接通过info命令查看agent菜单(‘high_integrity=1’代表该代理已被提升),如下图
我们先尝试privesc,因为我们需要提升权限来下载文件。在提升用户的目录权限之前,我们必须相对环境进行探测。Empire的命令模式可以让我们执行常用的Windows命令,如下图,我们可以看到我们的当前用户“dfm”是在管理员组里面。
通过我们假定的这个条件,由于“dfm”是本地管理员组,并没有提升到我们的agent中。为了提升这个,我们可以使用Empire的“bypassuac”命令来绕过用户权限控制提示并且提升到管理员权限。
如图,新的agent中包含了(*),这代表已经被提升了。
收集认证信息
现在,我们已经提升了目标机器的权限,我们需要从内存里提取信息。通过“ps”命令,我们可以看到这台机器上所有正在运行的进程。如果我们仔细观察,可以发现域用户“Mike”正在运行一个进程。
在我们的代理中运行mimikatz命令,我们就能获取到Mike的认证信息:
Mimikatz命令的输出将会回显这些信息。Empire将会自动的分析结果,并且添加一些后端的数据模型。这一点可以通过creds命令查看。
如果你想过来你的结果,可以直接通过creds <filer>命令来过滤出你需要的信息。例如你可以通过creds plaintext来得到数据库的认证信息,或者你可以通过creds Mike 得到“Mike”的登录信息。
用户枚举
我们已经有了“Mike”这个账户,接下来我们需要找到这个用户是做什么的。有不同的方法可以知道,例如,通过PowerView或者windows中的net命令。Empire提供的get_user模块可以返回所有的用户信息。你可以调到目录usemodule situational_awareness/network/powerview/get_user中执行:
把“Username”设置成“Mike”,输入execute执行,就会返回Mike的用户属性:
如果你使用PowerView查看一些常见的内容,你可能会觉得这个结果看起来跟Get-NetUser模块的输出相似。这是因为Empire有许多方法是参考了PowerView,这些模块的位置在situational_awareness/network/powerview/* ,这样我们就可以执行任意的PowerView方法而不需要全部加载整个脚本。
上图中可以看出,Mike是属于“Workstation Admins”群组。从前面的net localgroup Administrators 可以看出,“Workstation Admins”组是这个主机的一个本地管理员。这就意味着我们有可能通过这个账户获取到这个域中的其他成员的权限。
搜寻
通过这些已有的信息,我们可以开始找一些特殊的用户。可以使用situational_awareness/network/powerview/user_hunter模块完成这部分内容。这个模块使用的是PowerView中的Invoke-UserHunter方法,并且把它融合进Empire中。按默认配置运行它的时候,它将会查看有记录的当前域的所有与管理员的机器,并且回显:
看起来好像“DEV/will-da”有一个登录192.168.99.136的认证。我们来看看“Mike”的登录认证是否能等上这台机器。我们可以通过shell命令来获取:
然后,我们通过situational_awareness/network/powerview/get_localgroup模块检查哪些用户是属于administrators群组的,这个模块是一个类似PowerView中Get-NetLocalGroup的模块。
从这个模块的结果看,我们可以得到那个用户可以登上我们需要的这台主机:
从上图可知,用户组“Workstation Admins”是目标主机管理员组的一员。我们还可以通过设置-Recurse,这可以给我们能登录目标机的有效的用户。通过这份结果,我们可以知道“Mike”的认证证书可以获取到目标主机。
横向扩展
既然我们已经知道“Mike”可以让我们通过域管理”will-da”登上我们的目标主机,那么,我们来试试通过窃听一个Mike的进程来找找Mike身份验证的过程。我们可以看到,Mike有一个cmd的进程在运行,通过ps命令吧这个进程过滤出来:
我们可以通过steal_token <PID>命令来窃取这个命令,然后尝试访问目标主机的“C$”:
既然我们已经证实了可以访问,我们在远程机器上装一个代理。Empire有一个用于横线获取的配置选项,但是在这里,我们将使用WMI,我们通过usemodule lateral_movement/invoke_wmi命令加载这个模块:
设置Listener 和ComputerName选项之后,我们就可以开始执行这个模块了。如果你已经获取了目标主机,但是无法获取其中一个用户的工作环境,然而你有这个用户的认证。你就可以通过设置CredID字段来对应特征认证设置。
如果成功的话,我们将看到一个代理! 和mimikatz一样,我们掠夺了一台新主机
W00t,我们现在有了明文的与管理员凭证。
有一点很重要的是,在横向移动WMI后,你讲面临一个“double-hop problem”的问题,意味着你的新代理无法用于做跳板。你可以通过注入到另一个进程或者窃取另一个用户身份令牌来解决这个麻烦。我们的情况中,直接通过management/psinject模块就行,我们找到“will-da”的进程:
Psinject模块需要填写2个参数,你的新代理需要的监听器和你想要注入进程的PID。
通过在域管dev.lab.local在域控制器上运行shell dir命令验证我们的权限。首先,我们通过situational_awareness/network/powerview/get_domain_controller模块确定我们当前的域控制器:
现在,我们来验证权限:
信任跳转
用DEV的域管理员凭证可以做的事情很多,但是我们真正想得到的是lab.local的父域中的企业管理员权限。为了确认dev—>lab的信任关系的存在,我们可以使用situational_awareness/network/powerview/get_domain_trust模块:
从结果中可以看出,dev.lab.local 和他的父域lab.local是双向信任。既然如此,我们可以用子域的DA证书来控制整个域!在此之前,我们还需要一些信息。
首先,我们需要得到父域的SID,这一点可以通过分析LAB/krbtgt账户,通过management/user_to_sid模块得到该用户的的安全标识:
接下来我们需要得到krbtgt账户在dev.lab.local子域的哈希值。这一点,Empire已经帮我们实现了,通过credentials/mimikatz/dcsync模块。我们所要做的仅仅是设置UserName选项:
可以看到,Empire已经把结果都整理好了:
我们现在已经有了我们需要的所有信息,这些可以让我们绕过整个域的root权限。Empire中credentials/mimikatz/golden_ticket模块已经实现类似Mimikatz中的 Golden Ticket函数的功能。由于 DEV/krbtgt的哈希被收集到凭证库,我们只需要在Golden Ticket模块中输入证书编号能查看到。接下来我们需要做的就是指定一个用户和一个特定的外部SID。在设定SID的时候,我们把结尾的“502”去掉,并且加上“519”来构造一个lab.local/Enterprise管理员的完整的SID。
创建完后,我们就可以通过使用DCSync来提取父域lab.local 中的krbtgt的哈希值:
现在,我们有了krbtgt账户在这两个域中的所有哈希值:
有一点并不是必须的,但是,我们继续用krbtgt在lab.local中的哈希值重复Golden Ticket进程。我们只需要为lab.local域中的krbtgt用户指定CredID,用户名和域(lab.local),因为模块已经记录下了sid的设置:
如上所述,我们可以用父域(lab.local)中的krbtgt账户创建另一个Golden ticket。
为了确保一切顺利进行,我们可以通过C$测试lab.local域控制器的试用权:
就到这里,希望这篇文章能够清楚的向大家展示从刚开始的初始化设置到最后的完整控制。非常感谢。
* 文章来源: enigma0x3 ,FB小编/老王隔壁的白帽子翻译,转载请注明来自FreeBuf黑客与极客(FreeBuf.COM)