挖掘服务器消息块（SMB）中的隐藏宝藏

David Fletcher //

服务器消息块（SMB）共享可能给组织带来重大风险。公司通常缺乏对SMB共享所代表暴露的真实理解。有效管理通常需要一个健全的信息管理程序，专注于识别关键信息所在位置，积极控制对该信息的访问，并定期审计权限和访问模式。

通常，当组织被问及敏感数据的发现时，管理员会立即表示映射的网络驱动器会定期审计敏感内容，并且这些驱动器的权限受到严格保护。

不幸的是，映射的网络驱动器通常只是任何给定网络上内容暴露的冰山一角。在本文中，我们将逐步介绍一种方法，以大规模识别通过SMB共享可能暴露的敏感内容。在文章末尾，将提出减少环境中暴露量的策略。

大规模内容发现

SMB枚举的一个常用工具是PowerSploit的PowerView脚本。它已被移植到其他语言，其大部分功能作为BloodHound项目的基础。两个功能对于在Windows Active Directory（AD）网络上执行发现最有价值。第一个是Get-NetComputer，用于收集目标计算机名称，以便我们可以创建分类列表来分析网络共享。第二个是Invoke-ShareFinder，它实际上为我们执行枚举，尽职地向每台计算机请求共享列表，并检查所选用户是否有访问权限。

在执行此活动时，最好从一个仅属于“Domain Users”组的用户账户开始。这将减少共享暴露的误报率，并识别最严重的案例，其中共享暴露给域中的每个人。在识别和缓解最坏情况后，可以添加其他组成员资格来模拟典型用户暴露的信息。

分类计算机列表创建

在评估共享内容时，我通常生成分类计算机列表，以便确切知道我在查看什么，它对攻击的潜在价值，以及我可能避免陷阱，如具有不完整Active Directory属性信息的蜜罐。这种策略也从防御角度有效。通常，在现代Windows网络中，数据中心资源上共享的内容比工作站段更多，数据中心资源的枚举可能不会显得异常，而较旧的操作系统（如Windows Server 2003、Windows Server 2008和Windows Server 2012 RTM）代表环境中的风险增加。

例如，所有这些操作系统都有一个共同特点，即启用了WDigest，这意味着内存中可能存在明文凭据。其他问题，如缺乏Microsoft支持（Windows Server 2003和Windows Server 2008）和环境中的年龄（由于配置漂移，可能更容易提升权限）也使它们从攻击角度具有吸引力。作为防御者，首先处理这些主机可能是个好主意。

在较小程度上，上述问题也存在于工作站段。然而，我们通常在这些环境中发现管理访问权限多于敏感内容。显然，这不是一个硬性规则，因为一个环境可能与另一个环境显著不同。

为了生成上述分类列表，我们需要获取PowerSploit的PowerView或SharpView。下面显示的命令适用于PowerView 2.0，但可以调整以适用于PowerView 3.0和SharpView。我个人更喜欢PowerView 2.0语法，但可以使用PowerView 3.0中的Get-DomainComputer和Find-DomainShare完成类似分析。

您可能需要在端点套件或端点检测与响应（EDR）工具中创建异常，以便成功检索和执行。脚本可以使用PowerShell下载摇篮检索，直接下载到磁盘，或复制并粘贴（原始形式）到PowerShell解释器窗口或PowerShell集成脚本环境（ISE）。以下命令将为所有典型的Windows操作系统生成分类列表。删除您环境中不存在的那些。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

PS C:\> iex(iwr “https://raw.githubusercontent.com/PowerShellEmpire/PowerTools/master/PowerView/powerview.ps1” -usebasicparsing)
PS C:\> Get-NetComputer –OperatingSystem *2003* | Out-File –Encoding ASCII Windows2003Hosts.txt
PS C:\> Get-NetComputer –OperatingSystem *2008* | Out-File –Encoding ASCII Windows2008Hosts.txt
PS C:\> Get-NetComputer –OperatingSystem *2012* | Out-File –Encoding ASCII Windows2012Hosts.txt
PS C:\> Get-NetComputer –OperatingSystem *2016* | Out-File –Encoding ASCII Windows2016Hosts.txt
PS C:\> Get-NetComputer –OperatingSystem *2019* | Out-File –Encoding ASCII Windows2019Hosts.txt
PS C:\> Get-NetComputer –OperatingSystem *XP* | Out-File –Encoding ASCII WindowsXPHosts.txt
PS C:\> Get-NetComputer –OperatingSystem *7* | Out-File –Encoding ASCII Windows7Hosts.txt
PS C:\> Get-NetComputer –OperatingSystem *8* | Out-File –Encoding ASCII Windows8Hosts.txt
PS C:\> Get-NetComputer –OperatingSystem *10* | Out-File –Encoding ASCII Windows10Hosts.txt

如果您有较差的Active Directory卫生（计算机账户存在于不再存在的设备上），过滤pwdLastSet属性以移除可能无响应的设备也很有用。默认情况下，在Active Directory中，计算机每30天重置与其账户关联的密码。通常，我在客户环境中为设备提供约6个月的宽限期。通常，除非您旨在避免检测，否则这不是必要的。完全枚举也可能产生完整结果（除非设备在活动时关闭）。

共享枚举

接下来，上面生成的分类列表用作Invoke-ShareFinder函数的输入。Invoke-ShareFinder简单地从列表中的每个资产请求共享列表，并且如我们将配置的那样，将检查我们使用的身份是否有权访问暴露的共享。每个分类列表的命令如下所示。唯一的变体是实际的输入列表和输出文件名。

1
2
3
4
5
6
7
8
9

PS C:\> Invoke-ShareFinder –ComputerFile Windows2003Hosts.txt -NoPing –ExcludeIPC –ExcludePrint –CheckShareAccess | Out-File –Encoding ASCII Windows2003Shares.txt
PS C:\> Invoke-ShareFinder –ComputerFile Windows2008Hosts.txt -NoPing –ExcludeIPC –ExcludePrint –CheckShareAccess | Out-File –Encoding ASCII Windows2008Shares.txt
PS C:\> Invoke-ShareFinder –ComputerFile Windows2012Hosts.txt -NoPing –ExcludeIPC –ExcludePrint –CheckShareAccess | Out-File –Encoding ASCII Windows2012Shares.txt
PS C:\> Invoke-ShareFinder –ComputerFile Windows2016Hosts.txt -NoPing –ExcludeIPC –ExcludePrint –CheckShareAccess | Out-File –Encoding ASCII Windows2016Shares.txt
PS C:\> Invoke-ShareFinder –ComputerFile Windows2019Hosts.txt -NoPing –ExcludeIPC –ExcludePrint –CheckShareAccess | Out-File –Encoding ASCII Windows2019Shares.txt
PS C:\> Invoke-ShareFinder –ComputerFile WindowsXPHosts.txt -NoPing –ExcludeIPC –ExcludePrint –CheckShareAccess | Out-File –Encoding ASCII WindowsXPShares.txt
PS C:\> Invoke-ShareFinder –ComputerFile Windows7Hosts.txt -NoPing –ExcludeIPC –ExcludePrint –CheckShareAccess | Out-File –Encoding ASCII Windows7Shares.txt
PS C:\> Invoke-ShareFinder –ComputerFile Windows8Hosts.txt -NoPing –ExcludeIPC –ExcludePrint –CheckShareAccess | Out-File –Encoding ASCII Windows8Shares.txt
PS C:\> Invoke-ShareFinder –ComputerFile Windows10Hosts.txt -NoPing –ExcludeIPC –ExcludePrint –CheckShareAccess | Out-File –Encoding ASCII Windows10Shares.txt

如果您有一个大环境，可以通过向Invoke-ShareFinder部分添加“threads”参数来更快地执行上述命令。这样做允许脚本以并行方式评估计算机列表的元素。生成的输出文件将作为我们敏感内容发现操作的来源，如下一节所述。

敏感内容发现

有了我们的共享列表，是时候找到那些隐藏的宝藏了！！！

在测试中，我通常一次生成一个列表，并单独搜索结果以识别运行相同操作系统的一组主机可能暴露的内容。然而，出于防御目的，大规模调查共享是有用的。这可以通过使用理解正则表达式和多文件搜索的工具最有效地完成。下面使用Notepad++文本编辑器演示了一些我最喜欢的搜索。类似的分析可以在Linux中使用cat、sort和grep实用程序完成。

首先，选择所有包含共享信息的文件，右键单击，并选择“Edit with Notepad++”。

同时打开所有文件后，我们将调查一些对组织构成风险的常见暴露。在给定环境中，可能存在更多案例。然而，以下分析仅用于说明由于SMB共享暴露而存在的潜在风险。

管理访问

可能在攻击上下文中最臭名昭著和有用的共享是“C$”和“Admin$”共享。发现这些共享意味着极有可能具有管理访问权限。要发现这些共享，我们可以使用Notepad++中的正常模式搜索功能，如下所示。选择Search > Find…菜单选项或Ctrl+F以显示此对话框。

在搜索栏中输入文本“Admin$”，选择正常搜索模式，并单击“Find All in All Opened Documents”按钮。

Notepad++搜索结果窗格将识别在打开的文件组中发现的所有实例。这种情况对攻击者来说可能是一笔横财。可能通过注册表或LSASS进程进行凭据转储。

部署共享

另一个最喜欢的目标是部署共享。系统中心配置管理器（SCCM）、Windows部署服务（WDS）和Microsoft部署工具包（MDT）用于以自动化方式在网络上部署新操作系统。

打开Find对话框，输入关键字‘REMINST’，使用正常搜索模式，并单击“Find All in All Opened Documents”按钮。

当这些主机上暴露的共享中的文件夹保护不当时，可能可以访问unattend.xml文件和Windows映像（.wim）文件。对这些资源的分析通常导致发现有效的本地或域凭据。

根文件系统共享

管理员可能在给定主机上共享整个驱动器。当这种情况发生时，驱动器上所有可访问的内容都暴露给有权访问共享的任何人。通常，唯一对读取访问有重大限制的位置是‘C:\Users’目录的子文件夹。默认情况下，可以检查系统文件夹（C:\Windows）、程序文件以及根文件夹（C:\）中创建的任何其他文件夹。

打开Find对话框，输入正则表达式‘\[a-zA-Z]’，使用正则表达式搜索模式，并单击“Find All in All Opened Documents”按钮。上面的正则表达式匹配包括反斜杠（使用两个反斜杠转义序列）后跟单个字母（括号内的文本是字符类定义，匹配小写和大写字母字符）后跟空格的文本。

搜索结果中列出的所有共享都值得调查。较旧的操作系统可能暴露了包含凭据的unattend.xml文件，服务器上的根共享可能包含非常有趣的内容。在上面的例子中，为什么域控制器、SQL服务器、IT实用程序服务器和包含主目录的文件服务器会共享驱动器的根？这些位置中的配置文件、脚本和其他内容可能暴露凭据。

应用程序/Web根共享

应用程序开发人员通常使用SMB共享在网络上发布项目更改。当这些共享没有适当限制时，网络上的用户至少可以浏览应用程序的源代码。

打开Find对话框，输入正则表达式‘inetpub|wwwr|web’，使用正则表达式搜索模式，并单击“Find All in All Opened Documents”按钮。上面的正则表达式作为多关键字搜索操作，所选关键字由管道字符分隔（注意，之间没有空格）。

包含自定义应用程序或Web应用程序源代码的共享是一个严重问题。在可能读取访问的情况下，攻击者可以调查源代码中的编程问题，检查配置文件中的凭据，并可能因此获得网络上某处的SQL访问权限。

在可能写入访问的情况下，情况变得更糟。如果项目文件和源代码暂存在目标共享上，攻击者可以将恶意代码嵌入项目文件或应用程序的源代码中。当项目构建或执行时，攻击者获得对托管服务器（或项目构建的任何地方）的访问权限。在应用程序服务器上，攻击者还可以部署恶意功能，嵌入或伪装为应用程序的合法功能。Laudanum项目仍然是我最喜欢的Web shell之一，可用于在Web应用程序服务账户的上下文中执行命令。

“备份”共享

备份共享在目标环境中常见。有时这些共享被发现暴露完整的数字备份存储。然而，更常见的是，共享似乎被管理员用于将数据库和其他资源迁移到新平台。

对于此共享，我们返回到正常搜索模式，输入关键字‘Backup’，并单击“Find All in All Opened Documents”按钮。

备份共享可能包含异常危险的内容。通常，根据我的经验，大多数这些共享包含常见SQL服务器实现的备份。然而，偶尔我们会发现一些极其有趣的内容。

‘VMWare’主机上的共享可能包含虚拟机磁盘（VMDK）文件；可能包括域控制器的那些。VMDK文件可以使用7-zip等工具分析，而无需实际在主机上安装软件。即使域控制器的VMDK文件已有几年历史，它可能包含许多有效和有用的凭据。考虑以下问题作为有用凭据存在的证据：

您是否曾在域中轮换过krbtgt账户的密码？ 您最旧的服务账户上的密码有多旧？ Active Directory数据库中是否仍然存在任何LM哈希？

信不信由你，我们在几次参与中发现并利用了这些条件。

宝藏丰富！！

上述条件只是冰山一角。在您自己的环境中，我相信其他机会会出现。凭记忆，我可以想到一打额外的搜索我喜欢进行。然而，此练习的目的不是全面识别我们在SMB共享上可以找到的所有坏东西。而是让您思考网络上正在共享什么以及您可以用来减轻相关风险的策略。

缓解策略

共享最小化

管理员应审查共享列表，以确定任何给定的SMB共享在观察到的访问上下文中是否必要和适当。任何发现不需要的共享应被禁用。剩余的共享应调整权限以解决最小权限和需要知道的要求。

权限调整

SMB共享包含两组权限。第一组是应用于共享文件夹的实际NTFS权限。第二组是分配给共享本身的共享权限。当用户浏览到SMB共享时，服务器应用这两组权限的最严格交集。

就NTFS权限而言，当管理员没有故意更改时，系统上的本地‘Users’组将对所有卷具有读取访问权限。默认情况下，在加入域的计算机上，‘Domain Users’组是本地‘Users’组的成员。这意味着任何经过身份验证的用户都可以读取未更改这些权限的卷中的文件系统。

就共享权限而言，除非管理员显式创建共享并分配域组具有访问共享的权限，否则默认权限是‘Everyone’组具有读取访问权限。

正如您可能已经知道的那样，在两种情况下使用默认条件创建的共享通常将允许‘Domain Users’组的任何经过身份验证的成员读取共享上的内容。

第二个策略是纠正我们早期工作识别的广泛共享中的这些权限。根据所考虑网络的范围和规模，这可能是一项艰巨的任务。

分段

分段简单地将目标网络细分为更可管理和功能性的块，以减轻管理负担。分段项目在设计阶段应始终牢记最小权限和需要知道（或访问）概念。最终目标是在网络上创建阻塞点，只有授权个人（或计算机）和协议能够基于功能需要在网络段之间传递。因此，真正的分段总是意味着在段之间实现适当的访问控制列表（ACL）。

在用户段上，应进一步采取此策略以防止工作站到工作站的通信。在Windows Active Directory（AD）网络上，工作站到工作站的通信应被视为异常。通常，攻击者可以利用工作站段内的横向通信来积累权限，以全面接管环境。通过防止这种通信，攻击者被迫直接攻击数据中心（或其他可访问）的网络元素。

此外，用户段应具有进入数据中心（或其他受保护段）所需的最小访问权限，且不多。标准用户工作站不应能够使用未经授权的协议直接访问网络上的关键资源。例如，标准用户工作站不应能够启动到服务器（尤其是域控制器）的RDP会话。同样，不应访问Web管理控制台，如VSphere、VEEAM和其他核心服务。

管理员应为其管理账户拥有专用工作空间（物理工作站、跳转主机、VDI），该空间无权访问电子邮件或互联网。管理网络段应允许访问在工作站段上受限制的必要资源。

实施上述一般指南将使从用户工作站段访问多余网络共享成为不可能。存在许多有效分段的选项，包括：

基于网络的防火墙 基于主机的防火墙 网络基础设施

下面显示了说明所述条件的简化图。

用户和实体行为分析（UEBA）

UEBA不像前面的例子那样直接减轻与SMB共享相关的暴露。然而，它可以用于主动识别用户活动何时偏离既定基线。

当发生显著偏差时，会向信息安全团队生成警报，以便可以启动对活动的调查。显著偏差通常根据UEBA平台中的阈值定义。在我们的案例中，如果用户与计算机交互或浏览到过去30天内未观察到的超过30个共享，则会触发警报条件。

UEBA并非万无一失。具有持久访问权限的攻击者可能通过缓慢扩展对UEBA解决方案显得正常的主机或共享群体来低于雷达飞行。攻击者可能需要证据表明UEBA已就位才能采取此行动。

攻击者还可以执行手动分析以识别可能对敏感数据发现更有价值的主机。上下文线索通常出现在主机名、分配给用户的组、Active Directory中对象的描述以及其他位置，这将帮助攻击者制定环境中资源分析的优先顺序。

额外保证

在您采取措施消除环境中不必要的SMB共享后，您可能希望有一些额外的保证，即敏感内容不再暴露给未经授权的方。

我们发现任意敏感内容的最喜欢工具之一是Snaffler。Snaffler能够查询Active Directory以识别计算机账户，枚举可访问主机上的SMB共享，并彻底检查这些主机上暴露共享上的可配置文件内容。

一旦您构建了配置文件以支持您的搜索场景，该工具可用于定期审计环境以发现新的敏感数据暴露。运行时直接与暴露共享的数量和深度相关。因此，在尝试大规模发现之前，请确保使用上述一个或多个推荐的共享最小化步骤。

结论

组织不能等待攻击者暴露其自身环境中存在的敏感内容。采取主动立场并消除与内容发现相关的风险符合他们自己的最佳利益。在大多数情况下，在非标准共享上发现的信息首先不应暴露，并且可以提供比典型Active Directory攻击路径更容易的环境妥协路径。在许多场合，我们发现自己直接由于内容发现而获得对关键资源的管理访问权限。

现在出去找到隐藏在您自己环境中的宝藏吧！！！