什么是横向移动？

横向移动是一个广泛的 MITRE ATT&CK 类别，由九种不同的技术和许多子技术组成。

由于 ATT&CK 框架的其他领域之间的广度和联系，横向移动成为一个越来越有趣的类别，给防守者带来了许多挑战。

横向移动的类别确实与其他 ATT&CK 技术和类别有着内在的联系。例如，威胁行为者需要在环境中有立足点才能横向移动（初始访问）。此外，威胁参与者还需要某种凭证材料才能访问网络上的各种资产（凭证访问），并且需要有一个横向移动的目标（发现）。所有这些技术和类别协同工作，以使横向移动成为威胁行为者的可行选择。

将上述内容作为我们的背景，这篇博文的目的是深入挖掘横向移动的“原因”，并提供一些关于横向移动可见性和检测的技术防御指导。

为什么

让我们从威胁行为者的角度考虑一下横向移动。

您通过某种初始访问技术登陆网络并获得了一组凭据；现在怎么办？

也许你的目标可以通过最初的立足点来实现。

相反，这个最初的立足点可能无法提供满足我们虚构和邪恶目标所需的访问级别。

在这种情况下，我们作为威胁参与者必须尝试横向移动并转向网络上的其他系统，这些系统要么直接包含所需的目标，要么是完成通往所需目标的路径所必需的。

换句话说，横向移动决策使用“基于图表”的思维方式，而不是“基于列表”。

这可以用约翰兰伯特的一句话来概括——“防守者在列表中思考，攻击者在图表中思考”

特别是在 Active Directory 环境中，管理攻击路径是全面保护企业的一项关键任务。安迪·罗宾斯( Andy Robbins )的著作在这个领域是必读的。

我们现在了解什么是横向移动，并且也意识到横向移动技术需要威胁参与者的决策要素。

我们如何通过一个框架或模型来探索这个概念，以帮助我们作为防守者在横向移动防守上做出更明智的决定？

为此，我们可以求助于Jackson_T的工作以及他们关于Operational Mental Models的精彩博客文章。

这篇博文充满了发人深省的概念和框架，都可以深入探索。然而，为了我们的目的，让我们专注于“对称任务框架”

对称任务框架提出防御和进攻过程都是“一系列生成和识别任务”——这意味着攻击者和防御者都“执行生成或识别行为的任务”。最重要的是，在我们看来，这个框架突出了攻击者和防御者之间存在的对称性。

在横向移动的背景下，根据 Jackson_T 概述的模型，这意味着攻击者将基于一定程度的态势感知做出横向移动决策，然后可能会产生一种行为，从而留下可观察的伪影。此外，攻击者选项也根据一组贸易约束因素进行验证。

对称任务框架模型可以如下可视化（经许可重新发布https://jackson-t.ca/operational-mental-models.html）

让我们尝试将横向移动融入这个模型，并从防御的角度提出一些聪明的问题来问自己：

观察到的文物：

• 威胁行为者如何针对特定端点进行横向移动？
• 我们可以观察这个定位或枚举过程吗？
• 对于我们无法观察到的方面，还有哪些其他信息来源可以告知攻击者的目标选项？

贸易政策：

• 我们的网络拓扑如何影响特定资产的横向移动目标？
• 网络上的某些资产是横向移动的“更软”目标吗？
• 如果通过遥测或其他方式观察横向移动技术，观察到的技术告诉我们攻击者使用的方法和动机是什么？我们可以使用这些信息来预测未来的行为吗？

决定例外：

• 一个预期的或已知的“软”目标是否没有成为目标？
• 预期不匹配是否有助于发现强加于操作员或威胁参与者的技术或非技术约束？

程序逻辑：

• 横向移动是如何进行的？
• 我们是否缺乏对用于横向移动的某些协议的了解？

制作的文物：

• 横向移动技术会在主机层或网络层产生哪些工件？
• 我们是否存在可能使我们的研究结果产生偏差的覆盖范围？

通过这个模型，我们作为防御者现在可以在遥测收集、资产优先级以及有意义和可操作的警报创建方面做出更明智的决策。

如何

我们现在已经构建了横向移动框架，并使用“对称任务框架”模型提出了一系列面向防御的问题，以便在考虑构建横向移动检测和保护时问自己。

现在让我们进入技术层面，并处理一些 MITRE ATT&CK 数据，从威胁参与者的角度了解成功横向移动的先决条件，以及收集横向移动相关遥测数据所需的数据源TTP。

有很多方法可以对 ATT&CK 数据进行切片和切块。我们的最爱之一是使用MITRE Splunk 应用程序的 Supporting Add on

让我们看一下这个简单的查询，看看有多少 MITRE 技术和子技术属于横向移动类别：

index="attck" "kill_chain_phases{}.phase_name"="lateral-movement" 
| dedup name
| table name

根据使用的 ATT&CK 版本，您应该会看到在横向移动策略 (TA0008) 下返回的大约 20 种技术

让我们也看看使用以下查询执行横向移动需要哪些访问权限：

index="attck" "kill_chain_phases{}.phase_name"="lateral-movement"
| rename x_mitre_permissions_required{} AS permissions
| stats values(permissions)

返回的结果应如下所示：

因此，我们需要处理相对大量的技术，以及广泛级别的所需访问权限。事实上，根据 MITRE ATT&CK 数据，可以通过从普通用户帐户一直到系统级别访问权限的访问权限执行横向移动。

让我们使用以下查询将数据源添加到组合中，该查询计算横向移动类别下每种技术的适用数据源数量：

 index="attck" "kill_chain_phases{}.phase_name"="lateral-movement"
| rename x_mitre_data_sources{} AS datasources
| stats count(datasources) by datasources

使用饼图查看结果，我们看到以下内容：

有许多适用的数据源，我们的饼图中有相当大的块由进程创建事件和进程命令行参数表示。在我们的饼图底部，我们还看到了很多网络层数据源。身份验证日志在我们生成的饼图中也很突出。

当我们通过本文后半部分的检测部分时，上面突出显示的数据源确实将在整个过程中占据重要地位。

使用相同的数据“反转”我们还可以查看哪些技术具有最大的数据源覆盖率：

index="attck" "kill_chain_phases{}.phase_name"="lateral-movement"
| rename x_mitre_data_sources{} AS datasources
| stats count(datasources) AS datasource_count BY name
| table name,datasource_count

我们看到“远程服务”和“横向工具传输”在我们的饼图中大量出现，这不足为奇，因为“远程服务”包含六种子技术。同样，有许多方法可以执行“横向工具转移”，每个变体都可能包括一个独特的数据源。

我们现在已经为自己配备了一个用于思考横向移动防御的心智模型，并且我们还实施了 MITRE ATT&CK 框架，让我们对我们需要的数据源以及威胁参与者的要求有所了解执行横向移动技术。

使用这种智能，我们可以：

• 在横向移动的背景下构建更好的威胁模型
• 优先考虑遥测收集工作
• 优先考虑检测工程工作
• 形成更全面的威胁追踪假设
• 更好地识别遥测差距
• 更好地了解威胁参与者的决策
• 利用基于图形的网络保护视图

横向移动 TTP

到目前为止，我们已经广泛地对横向移动进行了背景化，并且还对 MITRE ATT&CK 数据进行了操作，现在让我们深入研究一些技术横向移动 TTP 检测。

T1210 – 远程服务的利用

此类别是指通过利用目标系统上运行的易受攻击的软件进行横向移动。也就是说，攻击者可能在系统 A 上站稳脚跟，执行扫描或探测，并确定系统 B 易受某种远程代码执行漏洞的攻击，然后利用该漏洞在系统 B 上站稳脚跟。

随着新漏洞的发现，这一类别不断变化。MS17-010以及CVE-2020-1472又名 ZeroLogon 是此类漏洞类型的很好示例。

我们在这里广泛地写了关于 Zerologon 的文章：https://www.lares.com/blog/from-lares-labs-defensive-guidance-for-zerologon-cve-2020-1472/

对于像 T1210 这样难以强化和计划的类别，值得回到我们的 MITRE ATT&CK 数据，尤其是数据源分析。

尽管我们无法预见未来在我们的网络中发现的漏洞，但我们可以确保收集相关的遥测数据。

如果我们查看用于识别 ZeroLogon 漏洞利用的数据源，我们可以看到数据源（例如数据包捕获、进程事件和身份验证事件）具有很强的特征。

T1570 – 横向工具转移

这是一个广泛的类别，包括在系统之间传输文件。在此示例中，让我们看一下 SMB 协议以及在传输文件时我们可以看到哪些事件。

对于这个测试，我们将生成一个 Metasploit 可执行文件，并将这个文件从 IP 命名为的主机复制到win10-0IP命名192.168.1.149为的主机win10-1``192.168.1.158

使用了不起的马尔科姆(https://github.com/cisagov/Malcolm）工具来监控我们的网络流量，当我们的文件传输时，我们可以看到以下有趣的事件：

我们可以看到一个文件已经被传输并且它是一个可执行文件。我们还可以看到该文件已从我们的 PCAP 中提取，并且可以在收集它的系统上进行进一步分析。

我们还可以使用 Sysmon，特别是事件 ID 3 (NetworkConnect) 来查看此文件传输活动。使用以下 Splunk 查询：

index=sysmon Initiated=false DestinationPort=445
| table SourceIp,DestinationIp,DestinationPortName,Image

我们可以看到通过 SMB 到我们的“受害者”机器的所有传入连接 ( win10-1)

使用以下 Arkime/Malcolm 查询与 Connections 视图相结合，我们可以图形方式检查 SMB 上的文件传输，必要时将结果限制为某些扩展：

ip.src == 192.168.1.149 && ip.dst == 192.168.1.158 && zeek.smb_cmd.command == CREATE && zeek.smb_files.name == *.exe*

网络监控，尤其是 Zeek 与 Malcolm 的结合，是我们威胁搜寻和检测工具库中一个非常强大的工具，我们可以关闭我们的runme.exe可执行文件并获取更多信息：

此时我们看到一个文件已传输到 SMB 管理员共享并且该文件未签名。

Malcolm 还可以使用Yara、ClamAV和Capa扫描雕刻文件

查看 ClamAV 签名，我们可以看到我们的可执行文件标记为：

同样，我们也可以看到 Capa 分析的输出：

我们现在有很多数据点可供使用，而无需执行文件。Zeek/Malcolm 数据还包含文件哈希，如有必要，可用于转回主机层。

T1563.002 – 远程服务会话劫持：RDP 劫持

RDP 劫持涉及威胁参与者控制或以其他方式“劫持”机器上现有的 RDP 会话。

在我们的示例中，我们有两个用户，RDPUser1并RDPUser2登录到同一台机器：

在上面的例子中，我们以身份登录RDPUser2并想要劫持的会话RDPUser1——我们可以使用 Mimikatz 来执行 RDP 劫持：

当攻击成功时，我们会看到 RDP 窗口RDPUser1

执行此操作时，将记录事件 ID 4778。此外，AtBroker.exe二进制文件由被劫持的用户执行 ( RDPUser1)。我们可以使用用户名作为我们的支点链接这些事件，以下 Splunk 查询尝试这样做：

index=winlogs OR index=sysmon EventCode=4778 OR (EventCode=1 AND Image="C:\\Windows\\System32\\AtBroker.exe")
| bin _time span=10m
| eval UserNameNormalized = coalesce(AccountName,user)
| stats values(ClientName),values(ClientAddress),values(SessionName),values(Image),values(ParentCommandLine) BY UserNameNormalized,_time

在这里，我们正在寻找事件 ID 4778 或 Sysmon 事件 ID 的存在以及执行AtBroker.exe- 然后我们正在规范化包含用户 ID 的字段，并将我们的结果分组到时间桶以及规范化的用户名价值。

运行查询后，我们得到以下结果：

当我们将上述活动与正常的 RDP 会话进行比较时；也就是说，用户打开某种远程桌面工具并连接到服务器，我们看不到 4778 事件，也看不到AtBroker.exe.

T1021.003 – 远程服务：分布式组件对象模型

为了测试 DCOM 横向移动，我们可以求助于Invoke-DCOM编写的https://twitter.com/424f424f

对于此测试，我们将使用以下MMC20.Application方法：

Invoke-DCOM -ComputerName '192.168.1.158' -Method MMC20.Application -Command "calc.exe"`此命令将`calc.exe`在 IP 为的机器上执行`192.168.1.158

使用以下查询，我们可以识别与进程建立的网络连接mmc.exe，并列出从该进程产生的任何mmc.exe进程：

index=sysmon (Image="C:\\Windows\\System32\\mmc.exe" OR ParentImage = "C:\\Windows\\System32\\mmc.exe")
| eval normalized_guid = coalesce(ParentProcessGuid,ProcessGuid)
| stats values(Image),values(CommandLine),values(DestinationIp),values(Initiated),values(SourceIp),values(User),values(ParentImage),values(ParentCommandLine) BY normalized_guid

看看我们的结果：

深入研究我们的 PCAP 数据并查看 RPC 协议，我们注意到以下网络工件：

Zeek 目前无法完全解析这些值，但在 Wireshark 中打开相同的 PCAP 文件会显示以下内容：

我们看到我们的端点值，从值开始，b19我们看到这转化为IProvideClassInfo

这也将我们引向上面突出显示的 DCOM 值和因果关系 ID——此信息很有用，因为它现在可以告诉我们此 RPC 流量包含 DCOM 执行的证据。

虽然这些数据在 Malcolm 中没有解析，但我们可以复制构成因果 ID 的十六进制字节并搜索这些字节：

查看搜索结果，我们只看到通过 RPC 执行 DCOM 的会话，而不是我们所有的 RPC 流量：

使用在我们的 Malcom 数据中寻找原始十六进制字节的相同技术，我们还可以查看 MMC20.Application 的 CLSID，该技术在以下论文中进行了概述：

https://atr-blog.gigamon.com/wp-content/uploads/2018/12/eu-18-Warner-Sirr-Network-Defender-Archeology-An-NSM-Case-Study-In-Lateral-Movement- With-DCOM-wp.pdf（第09页）

T1021.006 – 远程服务：Windows 远程管理

Windows 远程管理是一个棘手的横向移动 TTP，尤其是在您的环境使用 Windows 事件转发的情况下。

为了测试这个 TTP，我们将使用 Evil WinRM (https://github.com/Hackplayers/evil-winrm）

我们通过 WinRM 从我们的 Kali 机器到我们的受害者主机执行远程连接192.168.1.149

在这里，我们只是执行了一个简单的whoami命令，并快速浏览了通过 Evil WinRM 提供给我们的选项。

通过我们的 WinRM shell 执行的进程都将wsmprovhost.exe作为它们的父进程，以下基本查询将让您了解从wsmprovhost.exe

index=sysmon ParentImage="C:\\Windows\\System32\\wsmprovhost.exe"
| table Image,CommandLine,ParentCommandLine,User

结果：

转到网络层，我们知道 WinRM 在端口 5985 上运行，所以让我们看看我们的 PCAP 看看我们能找到什么：

我们在快速搜索中看到了很多 Windows 事件转发流量，所以让我们努力减少它。

我们可以使用 Malcolm/Arkime 强大的 SPI（Session Profile Information）视图，方法是点击 URI 按钮并点击“Open URI in SPI Graph”

此视图将向我们展示以图形或条形格式覆盖的时间线视图，其中包含通过 URI 细分的通过端口 5985 发送的会话数据量，我们的结果很有趣：

我们可以看到，用于 Windows 事件转发的合法 URI 似乎都命中了wsman/subscriptions端点，而底部的两个 WinRM 事件似乎很可疑，因为它们没有命中同一个端点。

我们也可以通过单击 Malcolm 中的 Graph Type 选项并选择“table”来以表格格式查看此数据：

使用这个视图，我们可以更清楚地看到我们潜在的异常 WinRM 连接：

让我们使用以下 Malcolm 查询深入了解包含我们奇怪的 URI 值的值：port == 5985 && http.uri == 192.168.1.149*/wsman*

在扩展通过我们上面使用的查询返回的会话时，我们看到一个奇怪的用户代理正在使用：

精神上参考本博客前面介绍的对称任务框架模型，值得思考的问题是，作为示例，Windows 事件转发的存在将如何影响或不影响对手的技术，特别是在使用 WinRM 横向移动的情况下。

T1021.005 – 远程服务：VNC

根据用于建立 VNC 会话的应用程序，服务器上可能会留下各种基于主机的工件。例如，TightVNC 在应用程序日志通道中记录会话身份验证。以下 Splunk 查询可用于获得对此数据的可见性。

index=winlogs EventCode=257  Name="'tvnserver'" 
| table  Message

使用以下 Maclolm 查询：protocols == rfb || protocols == vnc我们还可以在网络层了解 VNC：

T1550 – 使用替代认证材料

这个特殊的 MITRE 类别与使用标准用户名或密码以外的身份验证材料对系统进行身份验证的威胁参与者交谈。这种“备用”身份验证材料可以包括 cookie、Kerberos 票证、令牌和密码哈希。

有很多方法可以检测这种活动，我们在这里要强调的一种方法是一般的“访问异常查询”

让我们提出以下假设：我们期望网络中的特定用户在正常业务运营过程中访问特定的系统集。然后，我们假设对系统的意外登录应标记为异常以供进一步审查。

这个相对简单的动态可以总结为下图：

让我们在 Splunk 中实现这个逻辑，我们的假设将使用以下场景进行测试：我们的实验室有两个用户RDPuser1和RDPUser2两个服务器/工作站，Win10-0并且Win10-1- 根据我们实验室环境中的基线活动，我们知道RDPUser1登录Win10-1是正常活动并RDPUser1登录Win10-0是意外或异常活动。

我们首先使用我们期望有效/预期的值构建一个快速查找表：

接下来，我们使用以下查询逻辑：

``Looking at the index where the windows logs are, at the broad authentication tag and we are excluding computer accounts and some other noise``
index=winlogs tag=authentication (user=* AND user!=*$* AND user!=SYSTEM AND user!="DWM-2" AND user!="UMFD-2") AND dest!=localhost AND action=success
`<code>some fields within the authentication tag have [email protected] format and some jusst have user so we clean that up</code>`
| eval user = split(user,"@") 
| eval user = mvindex(user,0)
`<code>Perform our lookup, output will be an expected_login field with a value of "yes" if there is a match</code>`
| lookup auth_anomaly.csv user as user, dest as dest OUTPUTNEW expected as expected_login
`<code>if the expected_login field is a "yes" then count that as a normal login, otherwise label it an authentication anomaly</code>`
| eval auth_anomaly=if(expected_login=="yes","Normal Login","Authentication Anomaly")
| table user,dest,auth_anomaly

查看我们的结果，我们看到以下内容：

结果与我们的假设一致，并且RDPUser1执行的登录Win10-0被标记为身份验证异常。

尽管这是一个简化的示例，但围绕基线、建立预期行为查找和对该活动中的异常发出警报的概念是一个非常强大的范例，应该能够在这一广泛类别中捕获各种技术和策略。

下图概述了其他一些（非详尽的）登录特征，可用于确定特定身份验证是否是恶意的。

横向移动类别中的某些警报可以使用二元分类系统制作。即，将特定事件标记为恶意或良性的确定。

在查看一般“替代凭证材料”类别时，行为的二元分类不太理想。在对凭证盗窃和凭证材料的一般异常使用发出警报时，使用“视情况而定”方法是一个好主意。

这可以使用“超级查询”或类似 Splunk 的基于风险的警报框架来完成。这样的警报框架将允许您以更大的灵活性和上下文化警报恶意活动。

ATT&CK 的局限性

考虑我的同事Andy Gill在他的“ Old but Gold ”博客文章中概述的以下场景；攻击者获得 Active Directory 域中的有效凭据，并继续mmc.exe在受害者主机上打开并使用它连接到网络中的另一台受害者主机，然后他们继续在第二台受害者计算机上安排恶意远程任务。

通常的端点检测将应用于计划任务的创建。

但是，我们不希望看到进程创建事件，schtasks.exe但如果启用，我们将看到事件 ID 为 4698 的事件。

的某些元素T1053肯定参与了这种攻击场景，但T1053单独没有考虑到我们上面概述的虚构攻击场景的“远程”部分。

这个场景概述了使用 ATT&CK 框架作为检测覆盖范围的唯一和唯一晴雨表的危险。正如我们所看到的，这种特殊的技术并不完全适合任何现有的 ATT&CK 类别。

这个例子还强调了我们需要拥有不同的遥测数据集，以便能够重建这些恶意事件。

查看上面示例中为计划任务生成的 4698 事件，没有明显的信息告诉我们该任务是远程创建的。然后让我们转向网络层。

让我们使用以下 Malcolm 查询来查看受害者和目标主机之间发生的 RPC 流量：

ip == 192.168.1.157 && ip == 192.168.1.149 && protocols == dce_rpc

结果：

以“Sch”开头的 RPC 调用看起来特别有趣，经过一些过滤，我们最终得到以下结果：

现在，我们对攻击链有了更好的了解，并将根据这些数据确定源和目标，并能够将此活动与主机级遥测联系起来。

再次参考我们的对称任务框架模型，这个场景引入了一些有趣的问题，包括遥测收集和攻击者的交易技巧。从攻击者的角度来看，考虑到环境中可用的遥测，这种创建恶意计划任务的方法可能比其他方法更隐蔽。

结论

这篇博文的目的是强调横向移动 ATT&CK 类别，它在威胁检测和响应的背景下向网络防御者提出了无数问题。

虽然很难解决问题，但使用心智模型、数据源分析以及基于一组丰富的主机、身份验证和网络层遥测的智能警报，网络防御者拥有识别和应对各自环境中的恶意横向移动所需的必要工具。

吸收了这篇文章中包含的材料后，如果您发现自己在思考：

• 横向移动给您的环境带来的风险
• 是否正在进行必要的遥测收集
• 您的环境中是否存在检测和响应功能，以便能够成功响应横向移动
• 您现有的工具集和流程是否会阻止或检测横向移动 TTP