最后更新于2023年8月31日星期四15:10:21 GMT

在Rapid7，我们喜欢一个好的渗透测试故事. 所以他们经常表现出聪明, skill, resilience, 对客户安全的奉献只能来自于积极尝试打破它! In this series, 我们将分享一些来自渗透测试台的我们最喜欢的故事，并希望强调一些您可以提高自己组织安全性的方法.

Performing a Red Team exercise at Rapid7 is a rollercoaster of emotions. 第一周以兴奋和乐观开始, 因为您有一个全新的客户环境需要深入研究. 所有资产和员工都在范围内，毫不留情. From a hacker mentality, 这真的是令人兴奋的释放与无限的可能性反弹在你的头脑中，你将如何突破边界, set persistence, laterally move, 并获得公司“皇冠上的宝石”.”

然后第一周结束了，你意识到这家公司已经锁定了他们的资产, 缺少开发和部署一个0-day, you’re going to have to turn to other methods of entry such as social engineering. Excitement dies down but optimism remains, until that first phish is immediately burned. 然后第二个失败了. Desperation to "win" kicks in and you find yourself working through the night, trying to find one seemingly non-existent issue in their network, 这一切都是为了获得第一个立足点.

One of our recent Red Teams followed this emotional roller-coaster to a ‘T’. 我们的任务是攻击一家软件开发公司，最终目标是访问他们的代码库和云基础设施. We had four weeks, 两位Rapid7渗透测试顾问和许多红牛来破解我们所掌握的所有东西. 头两天我们都在表演 开源情报(OSINT) gathering. 这一阶段是一种被动侦察方法, 我们在网上搜索目标公司的公开信息. Areas of interest included public network ranges owned by the company, domain names, recent acquisitions, 公司内部使用的技术, 以及员工的联系方式.

Our OSINT revealed that the company was cloud-first with a limited external footprint. They had a few HTTPS services with APIs for their customers, 软件下载门户, 客户票务系统, the usual. Email was cloud hosted in Office365 with Single Sign-On (SSO) handled through Okta. The only external employee resources were an Extranet page that required authentication, a VPN portal which required Multi-Factor Authentication (MFA) and a certificate, 电子邮件云托管在Office365, 和Okta使用MFA处理单点登录(SSO).

初步侦察后, we determined three possible points of entry: compromise one of the API endpoints, 利用有效载荷或MFA旁路对用户进行网络钓鱼, or guess a password and hope it can sign into something without MFA required. 我们花了头两天的时间梳理客户的产品API文档，并测试任何端点，这些端点可以在没有身份验证的情况下访问或被利用来获取有用的信息. 我们在这里受到阻碍，这是公司的光荣.

Gone Phishin’

Our optimism and excitement was still high, however, as we set our eyes on plan B, phishing employees. 我们发起了一个基本的网络钓鱼活动，伪装成一个新的第三方员工合规培训门户网站. 绕过web内容过滤, we purchased a recently expired domain that was categorized as “information/technology.然后我们创建了一个假的登陆页面，上面有我们的新公司标志和一个“用SSO登录”按钮.

员工们几乎没有意识到, 而他们看到的是正常的Okta登录页面, 这是一个代理网络钓鱼页面 Evilginx 这将捕获他们的证书和 认证Okta会话. 唯一明显的区别是URL. 在捕获员工的Okta会话后，我们将他们重定向回我们的假第三方合规平台, where they were requested to download an HTML Application (HTA) file containing our payload.

We fired off this phishing campaign to 50 employee email addresses discovered online, 确保任何在其标题中带有“信息安全”的人都从目标列表中删除. Then we waited. One hour went by. Two. Three. 与竞选团队没有互动. 恐惧开始袭来. 我们怀疑一整天的辛苦工作都被垃圾邮件过滤器吞噬了, or worse, 识别和域名立即被封锁.

With defeat looming, 我们开始准备第二次网络钓鱼活动, when all of the sudden our TMUX session with Evilginx running showed a blob of green text. A valid credential was captured as well as an Okta session token. We held our breath as we switched to our Command and Control (C2) server dashboard, fingers crossed, and there it was. 来自钓鱼用户工作站的回调. 他们打开了工作站的HTA. 它绕过了EDR解决方案，执行了我们的有效载荷. We were in.

The thrill of establishing initial access is exhilarating. However, it's at this moment that we have to take a deep breath and focus. 通过网络钓鱼进行初始访问是一件很脆弱的事情，如果用户报告了，我们将失去我们的外壳. If we trip an alert within the EDR, we’ll lose our shell. 如果用户晚上回家后重启电脑，我们就可以设置持久性, we’ll lose our shell.

First things first, 我们迅速将钓鱼页面上的HTA有效负载替换为良性负载，以防活动被报告，安全运营中心(SOC)对着陆页面进行分类. 我们不能让他们从我们的有效负载中提取入侵指示器(ioc)，并将其与他们环境中的初始访问主机相关联. From here, 一个运营商专注于设置持久性和识别横向移动路径，而另一个运营商使用被盗的Okta会话令牌在用户的云应用程序过期之前检查用户的云应用程序. 三小时后，我们还能进入, 侦察正在进行中, 我们发现了一些有趣的 Kerberoastable service accounts that if cracked would allow lateral movement.

事情正朝着我们的方向发展. 然后一切都崩溃了.

在感觉像是成功的高潮时，我们收到了另一个成功的带有凭据的网络钓鱼. 我们破解了使用kerberos提供的服务帐户密码，并且……丢失了初始访问shell.  查看员工的Teams消息, 我们看到SOC发来的消息，询问他们的资产是否有可疑活动，因为他们准备隔离它. 我们又累又泄气，只好从头开始. But, like all rollercoasters, 当我们意识到最近捕获的凭证是帮助台团队的实习生时，我们开始上坡. While the tier one help desk employee didn’t have much access in the company, they could view all available employee support tickets in the SaaS ticketing solution. Smiling ear to ear, we assumed our role as the helpful company IT helpdesk.

Hi, We’re Here to Help

我们很快制作了一个有效负载，它利用了与恶意DLL一起打包的合法Microsoft二进制文件, loaded in via AppDomain 注射，并包装成一个漂亮的 ISO. 然后，我们确定了一名员工，他向服务台提交了一个请求，请求帮助连接一个抛出错误的内部应用程序. Taking a deep breath, we spoofed the help desk phone number and called the employee in need of assistance.

“你好，女士，我是IT服务台的亚瑟. We received your ticket regarding not being able to connect to the portal, 我想和你一起解决问题. Is this a good time?”

Note: you might be wondering what the employee could have done better here, but in the end, the responsibility lay with the company not having multi-factor on their help desk portal. 作为服务台，它为我们提供了回答员工可能提出的任何问题所需的信息.

The employee was thrilled to get assistance so quickly from the help desk. 我们甚至付出了额外的努力，花时间试图解决员工的实际问题, 感谢我们的努力. Finally, we asked the employee to try applying “one last update” that may resolve the issue. 我们引导他们去一个网站托管我们的有效载荷, download the ISO, open it, and run the “installer.” They obliged, as we had already built rapport throughout the entire call. Moments later, we had a shell on the employee’s workstation.

With a shell, 服务帐户凭证被破解, and all the noisy reconnaissance out of the way from our first shell, 我们直接进入了横向运动. The service account allowed  us to access an MSSQL server as an admin. 我们挂载了服务器的C$驱动器，并找到了已经安装的使用微软的程序 .NET framework. 我们上传了一个恶意DLL和配置文件，并使用 Windows管理工具(WMI))，再次利用AppDomain注入加载我们的DLL. Success! We received a callback to our new C2 domain from the MSSQL server. 横向运动，第一跳，完成.

Using Rubeus, 我们检查了内存中的Kerberos票据，发现了一个为Domain Admin用户缓存的Kerberos票据授予票据(KRBTGT). KRBTGT可以用在 Pass-the-Ticket (PTT) 攻击以验证帐户身份, 也就是说我们拥有域名管理权限直到门票在大约四小时后到期. Everything was flowing  and we were ready for our next setback. But it didn’t come. Instead, 我们使用票据对云管理员员工的工作站进行身份验证，并在主机上建立另一个shell. Luckily for us, the company had everyone’s roles and titles in their Active Directory descriptions, 员工工作站还在描述字段中包含相关的员工名, which made identifying the cloud admin employee’s workstation a breeze.

在云管理员的工作站上使用我们的shell, 我们执行了自己的Chrome cookie提取器, “HomemadeChocolateChips,” in memory, 它催生了Chrome与调试端口和 extracted all cookies 从当前用户的配置文件. This provided us with an Okta session token, which we used in conjunction with a SOCKS proxy 通过员工的机器访问来自内部IP地址的Okta仪表板. The company had it configured such that once authenticated to Okta, 它来自于公司的IP领域, Azure Okta chiclet没有再次提示MFA. With a squeal of excitement, we were into their Azure Portal with admin privileges.

In Azure, 在虚拟机的配置和操作选项卡下有一个方便的功能，称为“运行命令”.这允许管理员按照它的说明执行操作, 在虚拟机上运行PowerShell脚本. 好像不能再轻松了, we identified a virtual machine labeled “Jenkins Build Server” with “Run Command” enabled. 运行一个快速的PowerShell脚本下载我们的zip文件与后门的合法二进制文件, expand the archive, and then execute them, 我们在构建服务器上建立了C2立足点. From there we found GitHub credentials utilized by build jobs, which let us access our objective: source code for company applications.

Exhausted but triumphant, with bags under our eyes and shaking from the caffeine induced energy, 我们设置了几个长途C2连接，以便在评估结束时保持持久的网络访问. 我们还会见了客户，以确定我们的下一步, such as intentionally alerting their security team to the breach. Well, after a good beer and nap over the weekend, that is.

前面的故事是几个最近的攻击工作流的合并，以混淆客户端身份并展示一个内聚的评估.