如果不了解现网中正常的SMB流量，则通过网络流量检测ShareFinder将产生大量的误报。我们建议针对正常的SMB通信活动建立行为基线。用于区分正常和异常的SMB活动。总的来说，使用多个不同属性默认配置下的ShareFinder的流量是比较独特的，下表展示了当执行ShareFinder时产生的SMB通信行为：

从上表中我们可以总结出以下几个特征进行检测：

• 探测每个主机时都会请求 IPC$, C$, ADMIN$ 共享

• 在域环境中除了请求三个常用共享路径，还会请求域控服务器默认共享路径SYSVOL，在文件服务器上会请求名为“Files”的共享路径

• 每个请求之前的延迟较短，大约2秒（不同的网络环境可能存在差异）

• SMB请求是一对多的访问方向，从单一的源IP到多个目的服务器IP

    将以上行为特征进行组合，就可以很好地在网络中检测扫描共享资源的行为。

    Sigma规则：

https://github.com/The-DFIR-Report/Sigma-Rules/blob/main/rules/network/zeek/zeek_smb_mapping_invoke-sharefinder_discovery.yml

如果只依赖TCP连接上的行为特征，可能会检测到其他的异常行为，例如端口扫描。使用基于TCP连接会话的方法进行分析，可能会存在误报的情况，例如网络中的漏洞扫描平台发出的流量，或者网络中的统一管理运维审计等平台发出的流量。

ShareFinder支持使用-Ping参数，对多个目标进行存活探测。与上述SMB流量一致，ICMP存活扫描也是一对多的访问行为。

ICMP 回显请求并不能作为文件共享扫描行为特征的单一检测特征。但是出现ICMP扫描行为时，说明网络中源IP存在主机探测的扫描行为。

ShareFinder支持针对给定的主机列表进行扫描。但默认不指定目标的情况下，会使用LDAP协议获取网络中的计算机列表。在下面的例子中，通过发送CN类查询请求，使用通配符设置多个属性例如：dnshostanme、operatingsystem和servicePrincipalName，从域中查询出所有计算机列表。

(&(&(&(objectClass=Computer)(dnshostname=*))(operatingsystem=*))(servicePrincipalName=*))

分析师注释：如以上范围较广的LDAP查询，并不能说明这是一个网络共享扫描行为。而只是表示网络上的某些内容正在尝试查找计算机列表。像这样的事件应该与上面讨论的其他活动相关联，以便最终确定它是否是网络共享扫描行为。

在我们过去一年的报告中有五个案例都是使用Cobalt Strike会话启动的 ShareFinder。虽然在极少数情况下我们可以通过命令行调用检测脚本执行，但更好的检测方法是检测 PowerShell 日志（https://www.mandiant.com/resources/blog/greater-visibility）。下面为攻击者的调用示例，该示例是在来自 Microsoft-Windows-PowerShell/Operational 事件 ID 4103（模块日志记录）事件中捕获的。

常用的检测位置是在4103日志中检测ShareFinder模块的加载，例如以下Sigma规则：

https://github.com/The-DFIR-Report/Sigma-Rules/blob/main/rules/windows/powershell/powershell_module/posh_pm_invoke-sharefinder_discovery.yml

这个数据也可以在4104日志中获取。

如果攻击者重命名函数以试图逃避检测，我们可以尝试通过以下Sigma规则进行检测：

https://github.com/The-DFIR-Report/Sigma-Rules/blob/main/rules/windows/powershell/powershell_script/posh_ps_invoke_sharefinder_discovery.yml

与网络侧检测方法相比，通过PowerShell日志进行检测极大的规避了产生误报的可能性。

像网络侧检测那样，特殊的枚举域计算机和域用户检测行为在事件ID：1644中。事件 ID 1644 （https://www.manageengine.com/products/active-directory-audit/kb/system-events/event-id-1644.html）能够为针对域控制器进行的每个 LDAP 搜索记录一个条目，但是，这也会对检测产生大量噪音（无用日志）。默认情况下，事件ID：1644处于禁用状态，需要管理员手动启用（https://ramblingcookiemonster.github.io/Evil-LDAP-Queries/）。启用后可以在日志中看到请求源主机和查询响应结果。

需要注意的是，LDAP查询可以通过查询其他属性的方式实现。例如：上面的例子中我们查询请求中属性设置为objectClass=computer，这可以通过设置samAccountType=805306369进行等价替换。

( & (objectClass=computer) (dNSHostName=*) (operatingSystem=*) (servicePrincipalName=*))

与网络侧一样，网络共享访问也可以通过主机上的网络共享审计日志检测。来自安全事件 ID 5145（https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=5145） 能够记录对象对文件共享的访问以及源。

我们需要收集所有服务器上的对象访问日志进行分析，以上例子中我们可以发现与网络侧相同的特征：

• 探测每个主机时都会请求 IPC$, C$, ADMIN$ 共享

• 在域环境中除了请求三个常用共享路径，还会请求域控服务器默认共享路径SYSVOL，在文件服务器上会请求名为“Files”的共享路径

• 每个请求之前的延迟较短，大约2秒（不同的网络环境可能存在差异）

• SMB请求是一对多的访问方向，从单一的源IP到多个目的服务器IP

因此网络侧的检测逻辑可以同样适用于Windows 对象访问日志事件ID 5145。从源地址字段可以检测一对多的访问行为。但我们可能需要关联更多信息才能确定这是网络共享扫描行为。

以下是针对这一日志的Sigma检测规则：

https://github.com/The-DFIR-Report/Sigma-Rules/blob/main/rules/windows/builtin/win_security_invoke_sharefinder_discovery.yml

有许多工具可能与本文讨论的检测重叠，例如，PowerView 中的 Find-LocalAdmin 脚本能够枚举本地管理员用户，并且具有与上述类似的一对多 ICMP通信特征。尽管本文主要介绍ShareFinder的常见特征，但还有很多其他的工具也相对应的实现了一样的功能，例如：

Python 实现的共享扫描工具: https://github.com/p0dalirius/FindUncommonShares

.NET 实现的PowerView: https://github.com/tevora-threat/SharpView/

这些工具仍然可以通过基于网络或对象访问行为的类似活动进行检测。此外，如果攻击者试图混淆正在使用的脚本或程序，则通过关键字检测命令行日志或PowerShell日志会产生漏报。通常，负责资产清点、漏洞扫描的合法行为也会触发检测规则。