利用网络异常检测进程注入的新方法
编辑和评论补充:Tricia Howard
执行摘要
Akamai 研究人员开发了一种新技术,可通过分析网络异常来检测进程注入。
当前的检测机制主要依赖于与主机相关的因素,然而,这些因素可能会被新的攻击技术规避,因此,我们需要一种全新的方法来识别威胁。
随着攻击技术的发展,防御机制也必须不断发展,以减少误报的发生。
成功的进程注入攻击可能会导致一系列破坏性后果,包括 横向移动、权限升级以及后门安装。
我们的检测方法通过观察进程的网络行为,使威胁无所遁形,彻底暴露出来。
我们通过真实的案例来解释该方法的实际应用,这个案例与 WannaMine 加密劫持攻击有关。
前言
进程注入是几乎所有攻击操作中常用的手段之一。为了实施攻击,攻击者会不断寻找方法来操纵安全解决方案,例如,在已经活动的进程中隐藏和执行攻击负载。
注入技术是近年来发展迅速的威胁之一。这些高度复杂且仅依赖于内存的技术正在迅速取代传统的注入技术,因为传统注入技术很容易被现代安全解决方案检测到,例如端点检测和响应 (EDR)。
无论攻击者的最终目标是什么,一旦成功实施注入攻击,他们就会试图进行横向移动、执行网络扫描或安装侦听器作为后门。这就像是一场猫捉老鼠的游戏:攻击者找到一种新的攻击媒介,安全供应商便会相应地更新其检测机制,周而复始。
由于每个月都会推出新的检测技术,EDR 技术必须定期更新其检测机制,以减少误报。考虑到注入攻击一旦成功所带来的风险,我们需要思考一个问题:我们能否另辟蹊径?
大多数检测机制都会使用跟踪 API 调用、监测内存保护标志的变动、内存分配以及其他基于主机的特定痕迹等技术。然而,我们深知这些机制可能会受到新技术和威胁的影响而遭到操纵。 这些新的注入技术在与 EDR 绕过方法结合后,会使持续检测和拦截变得更加困难。也就是说,作为威胁搜寻人员,我们不能仅仅依赖防病毒 (AV) 或 EDR 解决方案来抵御这些基于主机的攻击,而是需要一种能够有效检测已得逞攻击的方法。
在这篇博文中,我们将介绍 Akamai Hunt 团队开发的进程注入检测技术。与之前提到的基于主机的特定痕迹的检测技术不同,这种技术可通过检测网络异常来识别进程注入攻击。 我们的技术关注进程的网络行为 ,相比于主机上的特定痕迹,如 API 调用或文件系统更改,网络行为更难以隐藏。我们将这种技术以及多种其他技术结合起来,共同检测恶意软件、横向移动、数据泄露以及客户网络中可能存在的其他类型的攻击。
我们的检测技术包含三个核心步骤:
按端口组对进程通信进行分类
建立移动窗口基线,确保正常的进程通信
将新进程数据与基线进行比较
请鼓励您的安全团队实施本文所述的逻辑。即使没有像我们在 Akamai Hunt中收集的大量数据,您仍然可以使用自己的数据来获得值得关注的结果。
建立基线,确保正常的进程通信
进程是如何通信的?
人们很容易认为进程通信基本上大同小异,也就是说,在不同的网络环境中,相同的进程会采用相同的通信模式。尽管某些进程的通信是这样的,但对于另一些进程则并非如此。我们通常认为操作系统中的原生进程在通信行为上是相似的,这些进程会使用相同的网络协议与相似的域进行通信。然而,实际上许多可变因素会影响这种假设。例如,操作系统版本、区域、代理服务器以及其他特定于网络的配置都可能影响进程的通信目的地和所使用的网络协议(图 1)。
通过分析从 Akamai Guardicore Segmentation收集的数据,我们发现端口使用存在不一致的情况。这可能会使检测变得非常困难,所以下一步我们需要找到一种方法,把数据解析成我们能够分析的格式。这就是端口组发挥作用的地方。
使用端口组对进程通信进行分类
通过研究,我们发现将相似的端口分组并与特定应用程序关联,可以为检测算法提供更丰富的上下文,从而更容易识别通信模式。这有助于我们发现通信模式中的异常情况。
例如,假设我们观察到一个特定的进程,它在一个网络中使用端口 636 和端口 389 进行通信,在另一个网络中使用端口 3268 和端口 3269 进行通信。由于这些端口都是轻量级目录访问协议 (LDAP) 的一部分,我们可以将它们归类为一个端口组:LDAP 通信。
虽然这种方法适用于大多数应用程序,但对整个有效端口范围进行分类并非易事。由于许多端口都被多个应用程序共同使用,因此当进程与其他软件共用一个端口时,这可能会导致进程分类错误。因此,我们只对主要由一种类型的应用程序使用的端口进行分类,并将高端口范围保留为一个端口组。
完整的端口映射可以在 附录 A中找到。
需要多少数据才能得出结论?
假设您在七台机器上观察到一个特定的进程正在运行,并且所有连接都使用 HTTPS 连接到同一个特定的 Web 服务器。您是否能够得出结论,该进程不使用任何其他通信形式?可能不行。
为了确定每个进程所需的数据量,我们选取每对进程和端口组,并计算在其中观察到的网络数量。
首先,我们只考虑在三个或更多客户网络中出现的进程。如果一个进程仅出现在不到三个网络中(在我们的数据集中有数百个网络),那么我们很难对其网络配置文件做出有把握的决策。
接下来,我们会根据不同客户之间网络行为的差异来确定进程的稳定性级别。如果一个进程在所有客户中都使用相同的端口组进行通信,那么我们可以认为它是 稳定的。如果一个进程在每个客户网络中使用完全不同的端口组进行通信,我们则认为它是 不稳定的。
我们还增加了 前 12 个、25 个和 100 个 稳定性级别,这些稳定性级别仅考虑前 12 个、25 个和 100 个常用端口。我们还引入了一个 半稳定 级别,该级别忽略高端口范围(即端口号高于 49151 的端口)。
支持与置信度
如果您正在处理从单个网络中提取的数据,那么数据挖掘技术将为您提供有力的支持和置信度,这将有助于您评估数据集中的数据强度和相关性。
支持 度量了数据集中项集的频率;而 置信度 则度量关联规则中两个项集之间关系的可靠性。在我们的案例中:
支持(进程) =(包含进程的数据点数)/(数据点总数)
支持(进程 –> 端口组) =(进程在特定端口组上通信的数据点数)/(包含该进程的数据点总数)
数据点是一个独特的数组:[主机,进程,端口组]
我们设定了一个阈值,用于确定进程应该具备的最小支持,同时为端口组设定了另一个阈值,以确定其应具备的最小置信度。这些阈值被视为基线的一部分。这也 是 Apriori 算法的第一步,这是一种在大数据集中发现模式的流行算法。经过评估后,我们选择了那些能够提供值得关注的发现并且具有低信噪比的值。
建立移动窗口基线
我们的检测技术的工作原理是将每个进程的通信与过去的行为基线进行比较。
为此,我们将某一天发生的所有进程通信与基于前一个月数据的基线进行比较(图 2)。
这有助于我们及时适应客户网络的趋势,因为在第二天,我们将考虑第一次观察到的网络变化、系统部署和工具。
处理常见的误报
某些应用程序设置可更改进程的网络配置文件。如果将某个应用程序设置从使用 IP 地址更改为使用主机名,它将开始产生 DNS 流量。对于内部代理服务器的使用也是如此,每个网络可能使用不同的端口来实现相同的目的。其他目标端口倾向于产生更少的误报,并且允许按每个客户单独列出,以保持原始逻辑的完整性。
为了减少误报的数量,生成的每个告警将使用以下逻辑进行检查:
如果进程的异常端口是 DNS/代理端口:
提取目标 IP
检查前一个月有多少资产在同一端口上与同一目标 IP 进行了通信
如果该数字大于网络主机数量的 20%,则将告警标记为误报
这个逻辑有助于处理网络特定设置中最嘈杂的两种通信类型:DNS 和代理通信。
检测真实的威胁:来自 Hunt 客户的攻击示例
利用我们为 Hunt 客户开发的全新方法,我们检测到五个偏离各自通信基线的进程。这五个系统原生可执行文件都使用一种与 Web 相关且非常特定的端口通信模式。它们通过使用服务器消息块 (SMB) 协议,发起与网络中其他资产的通信(图 3)。
通过观察这些进程的基线,我们可以发现它们并没有发起 SMB 通信(图 4)。
在告警调查过程中,我们发现文件 C:\Windows\NetworkDistribution\svchost.exe 在两台主机上运行,其中一台主机还检测到了文件
C:\Windows\System32\dllhostex.exe。
在另一台机器上,我们发现了一段值得注意的恶意脚本(图 5)。
正如您所看到的,该脚本触发了一个可执行文件,添加了一个 Windows 防火墙规则,并将端口 65531-65533 的通信传输到一个合法的 DNS 服务器上。该恶意软件还使用“Bluetool”计划任务实现持续运行,即每 50 分钟运行一个经过编码的 PowerShell 命令,以下载另一个攻击负载。
我们跟踪特定痕迹,发现了 WannaMine,这是一种仍然活跃的加密劫持攻击。利用未打补丁的系统和被 EternalBlue 入侵的网络,是该攻击常用的手段。
在对比过去的活动和此次攻击时,我们发现攻击者对他们的工具集进行了一些改动(图 6)。 我们注意到,这是攻击者首次将代码注入到合法的系统进程中。
我们的攻击 |
过去的攻击 |
|
---|---|---|
主要的计划任务 |
Bluetool |
蓝牙,黑球 |
主要的可执行模块 |
msInstall.exe |
svchost.exe |
次要的计划任务 |
GZAVwVOz |
DnsScan |
拦截入站 SMB 流量 |
✘ |
✔ |
注入到系统进程 |
✔ |
✘ |
图 6:这次攻击和过去攻击的比较
我们已将发现的所有问题、相应的补救措施以及网络策略建议及时通知客户。
总结
在威胁和攻击技术领域,拥有准确且高效的检测方法至关重要。每个网络都是一个独特的生态系统,面临着特定的挑战,因此找到一种“标准化”的检测方法非常困难。许多企业都尝试检测攻击,但都不成功,原因可能是攻击者使用了新技术,也可能是检测工具本身过于复杂。
通过关注进程的通信模式,我们可以全新的方式,增强传统检测技术的有效性。通过将此模式分析与我们庞大的数据库相结合,我们可以创建并应用这种方法,高效地检测进程网络异常,从而在客户网络中找出攻击者。
Akamai Guardicore Segmentation 和 Akamai Hunt 服务 能够阻止勒索软件的传播和横向移动尝试,同时辅以检测服务,每当发生攻击时都会向您及时发出告警。
请试用!
我们建议您在自己的网络中尝试这种方法,了解它的工作原理。由于您的数据集有所不同,所以我们使用伪代码来提供实施逻辑,以便您可以进行适当的调整和修改。 请关注我们的微信公众号 ,与我们分享您的发现,并了解有关全球 Akamai 安全研究人员取得的最新研究成果。
附录 A:端口到端口组的映射
端口 |
端口组名 |
---|---|
22、23、992 |
Shell |
20、21、69、115、989、990、5402 |
FTP |
49 |
TACACS |
53、5353 |
DNS |
67、68、546、547 |
DHCP |
88、464、543、544 |
Kerberos |
80、443、3128、8443、8080、8081、8888、9300 |
Web/Proxy |
111 |
ONC RPC |
123 |
NTP |
135、593 |
RPC |
137、138、139 |
NetBIOS |
161、199、162 |
SNMP |
445 |
SMB |
514、601、1514 |
Syslog |
636、389、3268、3269 |
LDAP |
902、903、5480 |
VNC |
25、993、995,585、465、587、2525、220 |
|
1080 |
SOCKS |
1433、1434、1435 |
SQL |
1719、1720 |
H323 VOIP |
1723 |
PPTP |
1812、1813、3799、2083 |
RADIUS |
3306 |
MySQL |
3389 |
RDP |
4444 |
Metasploit Default Listener |
5432 |
PostgreSQL |
5601 |
Kibana |
5938 |
TeamViewer |
5900 |
VNC |
5985、5986 |
WinRM |
6160、6161、6162、6164、6165、6167、6170 |
Veeam |
7474 |
Neo4j |
8090 |
Confluence |
9001、9030、9040、9050、9051 |
TOR |
27017 |
MongoDB |
33848 |
Jenkins |
49151 – 65535 |
高端口 |