关于iPhone备份密码,我们已经发表了多篇文章,涵盖了备份保护的不同方面。在本文中,我们以简短的形式收集了有关在不同情况下可以执行的操作的最重要信息,一些软件建议以及一些其他实用技巧。

可能的情况

有两种典型情况,你可能会受到iTunes备份密码的影响。

如果你是取证专家,则可能会遇到以下情况:嫌疑人的iPhone已解锁(未设置密码或已知密码),但是启用了备用密码,并且你擅长的取证工具(无论是哪种密码)都会提示你输入密码。如果你是iPhone用户,则可能需要将数据从一个iPhone传输到另一个iPhone,例如升级设备时。而且,如果你很久以前设置了密码并忘记了密码,那么你将无法从备份中还原。你的另一个选择是云备份,但是这个选项并不是最好的,原因有很多,超出了本文的范围。

我们建议你阅读一些关于iPhone、iPad或iPod touch上加密备份的文章,其中包含一些解密信息,但是如果你需要更实用的手册,请单击此处

提取备份密码

没有什么比原始密码更好的了,好消息是,如果你是Mac用户或以专家身份工作,不仅可以访问iPhone,而且还可以访问Mac,那么备份密码很可能存储在macOS钥匙串中。你只需要该Mac的密码即可。

1.png

所需软件:Keychain Acccess(免费;内置macOS实用程序)

密码破解

密码破解我们已经介绍过很多了,有时备用密码可能会被破解。在iOS 9及以前的版本中,这相对简单。但是,在iOS 10.2及更高版本中,破解密码只有在密码非常短或非常简单的情况下,或者你知道(记住)部分密码或密码模式,或者有一个非常好的单词列表时才有效。否则,即使在超级计算机上,破解密码也可能需要数年时间。

2.png

所需软件:hashcat(免费)或Elcomsoft Phone Breaker

重置

iOS 11引入了仅重置备份密码的功能,此选项在iOS 13和iOS 14的当前测试版中仍然可用,因此很可能仍然存在。步骤非常简单(如上面提到的Apple HT205220中所述):

在iPhone上,进入 [Settings] | [General] | [Reset];

点击[Reset All Settings];

按照步骤操作(系统将提示输入设备密码);

一些设置将被重置,备份密码将被删除。现在,你可以将设备连接到计算机并创建新的未加密备份,或者设置新密码而无需输入旧密码。

主要的问题是,设备密码也被删除了,这可能是致命的,特别是如果你不是在处理自己的数据,而是以取证专家的身份在工作,那事情就更糟了。简而言之,不要这样做。

软件要求:无。

其他方法

是的,有时你实际上并不需要恢复,重置或破坏备份密码。

首先,如果你只需要访问iPhone上的媒体文件(照片和视频),那么备份密码并不重要。无论密码是否设置,你都可以提取图片和视频。我们经常收到家庭用户甚至是朋友的请求,以寻求帮助以仅提取家庭照片,很多时候,照片(带有地理位置数据)也是取证专家所需要的,特别是当它们的时间很短,而且不需要重置或恢复密码的时候。

其次,对于选定的iPhone型号和iOS版本(目前,iPhone Xr/Xs/11上的iOS 13.5,以及旧型号上的所有iOS版本),你可以获得比备份中包含的数据多得多的数据,而且不需要备份密码。数据被提取为文件系统映像(不是标准备份格式),不能用于恢复其他设备。但是谁在乎数据是否是你所需要的?

最后一点是,除了文件系统映像之外,有时还可以从设备本身(从它的钥匙串)提取原始备份密码。很难说它是否为文件系统提取增加了一些价值,因为它比备份更完整,但是有时你可以使用此密码从可能包含一些已删除文件的旧备份中提取数据。

所需软件:Elcomsoft iOS Forensic Toolkit。

关于iPhone备份密码,我们已经发表了多篇文章,涵盖了备份保护的不同方面。在本文中,我们以简短的形式收集了有关在不同情况下可以执行的操作的最重要信息,一些软件建议以及一些其他实用技巧。

可能的情况

有两种典型情况,你可能会受到iTunes备份密码的影响。

如果你是取证专家,则可能会遇到以下情况:嫌疑人的iPhone已解锁(未设置密码或已知密码),但是启用了备用密码,并且你擅长的取证工具(无论是哪种密码)都会提示你输入密码。如果你是iPhone用户,则可能需要将数据从一个iPhone传输到另一个iPhone,例如升级设备时。而且,如果你很久以前设置了密码并忘记了密码,那么你将无法从备份中还原。你的另一个选择是云备份,但是这个选项并不是最好的,原因有很多,超出了本文的范围。

我们建议你阅读一些关于iPhone、iPad或iPod touch上加密备份的文章,其中包含一些解密信息,但是如果你需要更实用的手册,请单击此处

提取备份密码

没有什么比原始密码更好的了,好消息是,如果你是Mac用户或以专家身份工作,不仅可以访问iPhone,而且还可以访问Mac,那么备份密码很可能存储在macOS钥匙串中。你只需要该Mac的密码即可。

1.png

所需软件:Keychain Acccess(免费;内置macOS实用程序)

密码破解

密码破解我们已经介绍过很多了,有时备用密码可能会被破解。在iOS 9及以前的版本中,这相对简单。但是,在iOS 10.2及更高版本中,破解密码只有在密码非常短或非常简单的情况下,或者你知道(记住)部分密码或密码模式,或者有一个非常好的单词列表时才有效。否则,即使在超级计算机上,破解密码也可能需要数年时间。

2.png

所需软件:hashcat(免费)或Elcomsoft Phone Breaker

重置

iOS 11引入了仅重置备份密码的功能,此选项在iOS 13和iOS 14的当前测试版中仍然可用,因此很可能仍然存在。步骤非常简单(如上面提到的Apple HT205220中所述):

在iPhone上,进入 [Settings] | [General] | [Reset];

点击[Reset All Settings];

按照步骤操作(系统将提示输入设备密码);

一些设置将被重置,备份密码将被删除。现在,你可以将设备连接到计算机并创建新的未加密备份,或者设置新密码而无需输入旧密码。

主要的问题是,设备密码也被删除了,这可能是致命的,特别是如果你不是在处理自己的数据,而是以取证专家的身份在工作,那事情就更糟了。简而言之,不要这样做。

软件要求:无。

其他方法

是的,有时你实际上并不需要恢复,重置或破坏备份密码。

首先,如果你只需要访问iPhone上的媒体文件(照片和视频),那么备份密码并不重要。无论密码是否设置,你都可以提取图片和视频。我们经常收到家庭用户甚至是朋友的请求,以寻求帮助以仅提取家庭照片,很多时候,照片(带有地理位置数据)也是取证专家所需要的,特别是当它们的时间很短,而且不需要重置或恢复密码的时候。

其次,对于选定的iPhone型号和iOS版本(目前,iPhone Xr/Xs/11上的iOS 13.5,以及旧型号上的所有iOS版本),你可以获得比备份中包含的数据多得多的数据,而且不需要备份密码。数据被提取为文件系统映像(不是标准备份格式),不能用于恢复其他设备。但是谁在乎数据是否是你所需要的?

最后一点是,除了文件系统映像之外,有时还可以从设备本身(从它的钥匙串)提取原始备份密码。很难说它是否为文件系统提取增加了一些价值,因为它比备份更完整,但是有时你可以使用此密码从可能包含一些已删除文件的旧备份中提取数据。

所需软件:Elcomsoft iOS Forensic Toolkit。

DLL_Search_Order_Hijacking_blog_header_1010_350_75_s_c1.jpg

Context的智能和响应团队已经看到DLL搜索命令被滥用,作为在真实环境中进行网络入侵的一种手段。滥用DLL搜索顺序并利用这种机制来加载一个流氓DLL而不是合法的被称为DLL预加载,或者在MITRE ATT&CK框架中劫持。

在这篇文章中,你将了解更多关于DLL搜索顺序的基本原理,以及合法的二进制文件如何被武器化,并介绍一个通过DLL劫持自动发现适合有效载荷执行的二进制文件的工具。

关于动态链接库

动态链接库(DLL)是一个模块,它包含可以被另一个模块(应用程序或DLL)使用的函数和数据。这些函数从库文件中导出,以供依赖于它们的应用程序或DLL使用。为了使用这些函数,应用程序必须从库文件中导入它们。应用程序从模块导入函数有两种方式:隐式(加载时动态链接)和显式(运行时动态链接),让我们各看看。

隐式链接(加载时动态库链接)

当一个应用程序被打开时,Windows加载器采取步骤在内存中映射应用程序的可执行映像,并最终启动一个托管并执行其代码的进程。在加载过程中,加载器解析可执行映像的导入表,以便将导入的模块(动态链接库)映射到该进程的地址空间中。

可执行映像可能嵌入了描述Windows并行程序集上依赖关系的清单。在加载导入的DLL之前,并行管理器(SxS Manager)检查这个可执行文件的清单文件中存在的任何依赖项是否得到满足。如果是,则从路径中加载所需的模块。

对于其余的导入模块,加载程序首先检查由KnownDLLs注册表项(HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ KnownDLLs)设置的列表上是否存在要导入的所有DLL。如果是,加载程序将使用此注册表项指向的DLL的副本。否则,它将通过应用DLL搜索顺序来搜索模块。有关DLL搜索顺序的更多信息,请参见本文其他章节。

显式链接(运行时动态库链接)

应用程序可能需要使用DLL中的函数,这些函数在应用程序运行时动态加载。以这种方式加载DLL称为运行时DLL动态链接,这种类型的加载发生在应用程序调用LoadLibrary或LoadLibraryEx函数时。

这两个函数接受要加载的模块的名称,名称可以是模块的文件名,也可以是模块的完整路径。如果应用程序没有指定模块的完整路径,Windows加载程序将查找应用动态库搜索顺序的DLL。

DLL搜索顺序劫持及其识别方法

滥用DLL搜索顺序并利用这种机制使应用程序加载流氓DLL(而不是合法的DLL)被称为DLL预加载。之所以称为预加载,是因为攻击者可以将其DLL放在搜索顺序的前面,从而使应用程序加载此DLL,而不是合法的DLL。该技术在MITER ATT&CK框架(T1038)中记录为DLL搜索顺序劫持。在本文的以下各节中,我们演示如何滥用合法应用程序通过搜索顺序劫持来加载和执行Cobalt Strike信标有效载荷。

DLL搜索顺序劫持主要提供两个优点,使其成为一种有效的技术。第一个优点是可以用来逃避检测。武器化的应用程序通常是合法的经过签名的二进制文件,可以通过调用此DLL导出的函数在其地址空间中加载恶意DLL。因此,为了执行恶意DLL,自动化沙箱必须首先确定要调用或执行无害二进制文件的导出函数,并设置环境以加载恶意DLL。

该技术提供的另一个优点是可以提升特权,当在其地址空间中加载DLL的合法应用程序以提升的特权运行时,在其上下文中执行的任何代码都将以相同的特权级别执行。这意味着有效载荷DLL及其实现的功能将以与加载它的进程相同的特权执行。

识别用于劫持的候选DLL有两种不同的方法:静态分析和动态分析,就像恶意软件分析中采用的方法一样。动态分析包括执行应用程序和监视其加载的库。这可以通过监视API调用的工具(例如Procmon和API Monitor)来实现。静态分析方法包括使用IDA和Ghidra等反汇编工具来识别出现的特定API调用,而不执行应用程序。

这两种方法的主要区别在于,通过使用动态分析,可以显示用于加载时和运行时动态链接的大量候选DLL,而静态分析仅显示在运行时加载的候选DLL。

DLL搜索顺序

从Windows XP开始,启用SafeDllSearchMode选项时,模块将在加载时或运行时加载到应用程序的地址空间中,并且未明确指定模块的完整路径,或者未声明清单文件在可以查找依赖项的位置,操作系统按照定义的搜索顺序搜索DLL,该DLL包含以下内容:

从中加载应用程序的目录

系统目录

16位系统目录

Windows目录

当前目录(除非另有说明,否则与第一个相同)

PATH环境变量中列出的目录

当未启用SafeDllSearchMode时,以上搜索顺序略有不同,有关这方面的其他信息,请参阅Microsoft文档

当操作系统开始搜索应用程序导入的DLL时,除非指定了完整路径,否则首先搜索加载应用程序的目录。如果DLL不存在,接下来搜索系统目录,依此类推。当攻击者观察到应用程序的行为后,将他们自己的DLL放在搜索顺序的较早位置,以便应用程序加载该DLL而不是继续搜索时,就会发生滥用。Context的情报团队作为AVIVORE跟踪的威胁小组使用了这种技术,以实现在受害者环境中的有效载荷执行。

加载时动态链接的示例

为了说明加载时的加载情况,我们分析了一个已签名的Google可执行文件(GoogleCrashHandler-MD5:83bb030c71c9727dcfb2737005772c4e),Context的情报团队观察到该文件被用于入侵。

我们之所以关注此二进制文件,是因为它可以找到合适的候选人。这是什么意思呢?首先,它是来自受信任供应商的合法且经过签名的二进制文件。一旦执行了此应用程序,它将不显示可见窗口,并且在执行时终止,因此在执行此二进制文件时,不会使用户知道该二进制文件确实已在运行,并且进程不会停留在运行状态。最后一点同样重要,即使应用程序加载了恶意DLL,它也不会生成任何其他活动(例如弹出窗口),而这可能会引起用户的怀疑。因此,它可用作执行有效载荷DLL的杠杆。

为了识别此可执行文件尝试加载并可能被劫持的模块,我们将SysInternal的Procmon与以下过滤器一起使用:

1.png

应用过滤器后,我们得到以下候选DLL:

2.png

自动化DLL搜索顺序

为了武器化GoogleCrashHandler.exe,我们创建了一个自定义DLL,该DLL执行从CobaltStrike生成的beacon shellcode。我们将输出DLL命名为wkscli.dll,并将其放置在GoogleCrashHandler可执行映像所在的目录中。然后,我们打开了GoogleCrashHandler。下一张图片显示恶意DLL被映射到GoogleCrashHandler的地址空间中,并且启动了一个信标。

3.png

运行时动态链接的示例

为了说明运行时加载,我们分析了一个经过签名的Microsoft可执行文件(OleView-MD5:d1e6767900c85535f300e08d76aac9ab)。已签名的可执行文件用于加载DLL,该DLL随后解密了PlugX有效载荷。

让我们与Procmon一起查看该可执行文件一旦启动即尝试加载的DLL:

p.4_graphic_4_.png

为了确认此DLL是动态加载的,而不是在加载时加载的,我们使用API Monitor。通过挂钩LoadLibrary和LoadLibraryEx API,我们观察到该应用程序尝试动态加载多个DLL:

p.4_graphic_5_.png

将从Procmon和API监视器获得的数据进行关联,应用DLL搜索顺序确定所搜索的DLL为ACLUI.DLL。我们可以通过分析Ghidra上的可执行文件来做同样的事情。在定义字符串部分(窗口->定义字符串)我们搜索字符串ACLUI。出现了三个结果:

p.5_graphic_6_.png

然后,我们遵循对字符串ACLUI.DLL的引用,并最终完成对LoadLibraryW的调用:

p.5_graphic_7_.png

我们观察到LoadLibraryW API的参数不是完整路径,因此我们确认应用了DLL搜索顺序。

如果我们创建一个有效载荷DLL,将其放置在与可执行文件相同的目录中,然后运行该可执行文件,则会显示以下消息框:

p.5_graphic_8_.png

这意味着可执行文件从我们的有效载荷DLL请求一个不存在的函数,为了允许我们的有效载荷从应用程序执行,我们必须导出函数EditSecurity。以下屏幕快照显示了使用C / C ++代码执行此操作的方法:

p.5_graphic_9_.png

自动化DLL搜索顺序

就像我们对GoogleCrashHandler图像所做的一样,我们创建了一个自定义DLL,该DLL执行从CobaltStrike生成的beacon shellcode。我们将输出DLL命名为ACLUI.DLL,并将其放置在与OleView.exe可执行映像相同的目录中。然后,我们打开OleView。下一张图片显示恶意DLL被映射到OleView的地址空间中并启动了一个信标。

p.6_graphic_10_.png

缓解策略

基于我们所观察到的事件以及过去如何滥用DLL搜索顺序,我们可以推荐在这些环境中应用的特定最佳实践。这些建议旨在减少攻击面,限制潜在攻击的后果,并减少检测相关攻击所需的时间。

通常建议公司在其环境中部署功能和策略,作为功能的一部分,强烈建议部署事件检测和响应(EDR)软件。在策略方面,填充和维护授权在该环境中运行的所有应用程序的列表,并实现应用程序白名单,以防止不属于该列表的应用程序运行,这是一个很好的实践。为了检测流氓DLL,建议对环境中观察到的DLL进行频率分析。DLL的低频发生可能是值得进一步分析的指标。可以防止其他DLL劫持攻击的另一件事是启用SafeDllSearchMode并在系统上配置CWDIllegalInDLLSearch注册表。

软件开发人员也必须遵循最佳实践,例如,当应用程序在运行时加载模块时,建议为提供给LoadLibrary和LoadLibraryEx API的模块指定绝对路径,或使用API SetDllDirectory专门设置Windows加载器将从中加载提供的模块的路径。这样,就不会查找正常的搜索顺序。根据最佳实践,另一项建议是通过“应用程序清单”对加载的模块实施完整性检查。通过这样做,应用程序将防止恶意DLL的加载,并有可能将识别出的异常通知用户。

DLLHSC简介

DLLHSC是一个应用程序,旨在自动扫描提供的可执行映像,生成潜在顾客(以后可以手动评估)并报告利用DLL搜索顺序的潜在路径,最终目的是在地址空间中加载有效载荷DLL。通过搜索顺序劫持提供的图像。

操作模式

该工具实现3种操作模式,如下所述。

轻量级的模式

在内存中加载可执行映像,解析导入表,然后用有效载荷DLL替换导入表中引用的任何DLL。该工具将一个模块(DLL)放在应用程序目录中,该模块不存在于应用程序目录中,不属于WinSxS,也不属于KnownDLLs。

然后,它启动应用程序并报告是否执行了有效载荷DLL。有效载荷DLL在执行后会在路径C:\ Users \%USERNAME%\ AppData \ Local \ Temp \ DLLHSC.tmp中创建一个临时文件。如果临时文件存在,则表明扫描的应用程序可能被滥用。当某些可执行文件从它们加载的DLL导入函数时,当提供的DLL无法导出这些函数并因此满足提供的映像的依赖性时,可能会显示错误消息框。

但是,消息框表明,如果满足依赖关系,DLL可能是有效载荷执行的好候选对象。在这种情况下,需要进行额外的分析。这些消息框的标题可能包含以下字符串:“找不到常规”或“找不到入口点”。 DLLHSC会查找包含这些字符串的窗口,并在出现这些窗口时立即关闭它们并报告结果。

模块列表模式

使用提供的可执行映像创建一个进程,枚举此进程的地址空间中加载的模块,并在应用过滤器后报告结果。

该工具仅报告从系统目录加载的模块,不属于KnownDLL。结果是需要进一步分析的线索。然后,分析人员可以将报告的模块放在应用程序目录中,并检查应用程序是否加载了提供的模块。

运行模式

通过Microsoft Detours(Detours是微软开发的一个函数库,可用于捕获系统API)挂钩LoadLibrary和LoadLibraryEx API时,并报告在运行时加载的模块。

每次扫描的应用程序调用LoadLibrary和LoadLibraryEx时,该工具都会拦截该调用,并将请求的模块写入文件C:\Users\%USERNAME%\AppData\Local\Temp\DLLHSCRTLOG.tmp中。如果使用标志LOAD_LIBRARY_SEARCH_SYSTEM32专门调用LoadLibraryEx,则不会将任何输出写入文件。完成所有拦截之后,该工具将读取文件并打印结果。对于进一步的分析,我们感兴趣的是KnownDLLs注册表键中不存在的模块、系统目录中不存在的模块以及没有完整路径的模块(对于这些模块,加载器应用正常的搜索顺序)。

你可以在我们的GitHub页面上找到DLLHSC的源代码以及x86和x64体系结构的编译二进制文件。

DLL_Search_Order_Hijacking_blog_header_1010_350_75_s_c1.jpg

Context的智能和响应团队已经看到DLL搜索命令被滥用,作为在真实环境中进行网络入侵的一种手段。滥用DLL搜索顺序并利用这种机制来加载一个流氓DLL而不是合法的被称为DLL预加载,或者在MITRE ATT&CK框架中劫持。

在这篇文章中,你将了解更多关于DLL搜索顺序的基本原理,以及合法的二进制文件如何被武器化,并介绍一个通过DLL劫持自动发现适合有效载荷执行的二进制文件的工具。

关于动态链接库

动态链接库(DLL)是一个模块,它包含可以被另一个模块(应用程序或DLL)使用的函数和数据。这些函数从库文件中导出,以供依赖于它们的应用程序或DLL使用。为了使用这些函数,应用程序必须从库文件中导入它们。应用程序从模块导入函数有两种方式:隐式(加载时动态链接)和显式(运行时动态链接),让我们各看看。

隐式链接(加载时动态库链接)

当一个应用程序被打开时,Windows加载器采取步骤在内存中映射应用程序的可执行映像,并最终启动一个托管并执行其代码的进程。在加载过程中,加载器解析可执行映像的导入表,以便将导入的模块(动态链接库)映射到该进程的地址空间中。

可执行映像可能嵌入了描述Windows并行程序集上依赖关系的清单。在加载导入的DLL之前,并行管理器(SxS Manager)检查这个可执行文件的清单文件中存在的任何依赖项是否得到满足。如果是,则从路径中加载所需的模块。

对于其余的导入模块,加载程序首先检查由KnownDLLs注册表项(HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ KnownDLLs)设置的列表上是否存在要导入的所有DLL。如果是,加载程序将使用此注册表项指向的DLL的副本。否则,它将通过应用DLL搜索顺序来搜索模块。有关DLL搜索顺序的更多信息,请参见本文其他章节。

显式链接(运行时动态库链接)

应用程序可能需要使用DLL中的函数,这些函数在应用程序运行时动态加载。以这种方式加载DLL称为运行时DLL动态链接,这种类型的加载发生在应用程序调用LoadLibrary或LoadLibraryEx函数时。

这两个函数接受要加载的模块的名称,名称可以是模块的文件名,也可以是模块的完整路径。如果应用程序没有指定模块的完整路径,Windows加载程序将查找应用动态库搜索顺序的DLL。

DLL搜索顺序劫持及其识别方法

滥用DLL搜索顺序并利用这种机制使应用程序加载流氓DLL(而不是合法的DLL)被称为DLL预加载。之所以称为预加载,是因为攻击者可以将其DLL放在搜索顺序的前面,从而使应用程序加载此DLL,而不是合法的DLL。该技术在MITER ATT&CK框架(T1038)中记录为DLL搜索顺序劫持。在本文的以下各节中,我们演示如何滥用合法应用程序通过搜索顺序劫持来加载和执行Cobalt Strike信标有效载荷。

DLL搜索顺序劫持主要提供两个优点,使其成为一种有效的技术。第一个优点是可以用来逃避检测。武器化的应用程序通常是合法的经过签名的二进制文件,可以通过调用此DLL导出的函数在其地址空间中加载恶意DLL。因此,为了执行恶意DLL,自动化沙箱必须首先确定要调用或执行无害二进制文件的导出函数,并设置环境以加载恶意DLL。

该技术提供的另一个优点是可以提升特权,当在其地址空间中加载DLL的合法应用程序以提升的特权运行时,在其上下文中执行的任何代码都将以相同的特权级别执行。这意味着有效载荷DLL及其实现的功能将以与加载它的进程相同的特权执行。

识别用于劫持的候选DLL有两种不同的方法:静态分析和动态分析,就像恶意软件分析中采用的方法一样。动态分析包括执行应用程序和监视其加载的库。这可以通过监视API调用的工具(例如Procmon和API Monitor)来实现。静态分析方法包括使用IDA和Ghidra等反汇编工具来识别出现的特定API调用,而不执行应用程序。

这两种方法的主要区别在于,通过使用动态分析,可以显示用于加载时和运行时动态链接的大量候选DLL,而静态分析仅显示在运行时加载的候选DLL。

DLL搜索顺序

从Windows XP开始,启用SafeDllSearchMode选项时,模块将在加载时或运行时加载到应用程序的地址空间中,并且未明确指定模块的完整路径,或者未声明清单文件在可以查找依赖项的位置,操作系统按照定义的搜索顺序搜索DLL,该DLL包含以下内容:

从中加载应用程序的目录

系统目录

16位系统目录

Windows目录

当前目录(除非另有说明,否则与第一个相同)

PATH环境变量中列出的目录

当未启用SafeDllSearchMode时,以上搜索顺序略有不同,有关这方面的其他信息,请参阅Microsoft文档

当操作系统开始搜索应用程序导入的DLL时,除非指定了完整路径,否则首先搜索加载应用程序的目录。如果DLL不存在,接下来搜索系统目录,依此类推。当攻击者观察到应用程序的行为后,将他们自己的DLL放在搜索顺序的较早位置,以便应用程序加载该DLL而不是继续搜索时,就会发生滥用。Context的情报团队作为AVIVORE跟踪的威胁小组使用了这种技术,以实现在受害者环境中的有效载荷执行。

加载时动态链接的示例

为了说明加载时的加载情况,我们分析了一个已签名的Google可执行文件(GoogleCrashHandler-MD5:83bb030c71c9727dcfb2737005772c4e),Context的情报团队观察到该文件被用于入侵。

我们之所以关注此二进制文件,是因为它可以找到合适的候选人。这是什么意思呢?首先,它是来自受信任供应商的合法且经过签名的二进制文件。一旦执行了此应用程序,它将不显示可见窗口,并且在执行时终止,因此在执行此二进制文件时,不会使用户知道该二进制文件确实已在运行,并且进程不会停留在运行状态。最后一点同样重要,即使应用程序加载了恶意DLL,它也不会生成任何其他活动(例如弹出窗口),而这可能会引起用户的怀疑。因此,它可用作执行有效载荷DLL的杠杆。

为了识别此可执行文件尝试加载并可能被劫持的模块,我们将SysInternal的Procmon与以下过滤器一起使用:

1.png

应用过滤器后,我们得到以下候选DLL:

2.png

自动化DLL搜索顺序

为了武器化GoogleCrashHandler.exe,我们创建了一个自定义DLL,该DLL执行从CobaltStrike生成的beacon shellcode。我们将输出DLL命名为wkscli.dll,并将其放置在GoogleCrashHandler可执行映像所在的目录中。然后,我们打开了GoogleCrashHandler。下一张图片显示恶意DLL被映射到GoogleCrashHandler的地址空间中,并且启动了一个信标。

3.png

运行时动态链接的示例

为了说明运行时加载,我们分析了一个经过签名的Microsoft可执行文件(OleView-MD5:d1e6767900c85535f300e08d76aac9ab)。已签名的可执行文件用于加载DLL,该DLL随后解密了PlugX有效载荷。

让我们与Procmon一起查看该可执行文件一旦启动即尝试加载的DLL:

p.4_graphic_4_.png

为了确认此DLL是动态加载的,而不是在加载时加载的,我们使用API Monitor。通过挂钩LoadLibrary和LoadLibraryEx API,我们观察到该应用程序尝试动态加载多个DLL:

p.4_graphic_5_.png

将从Procmon和API监视器获得的数据进行关联,应用DLL搜索顺序确定所搜索的DLL为ACLUI.DLL。我们可以通过分析Ghidra上的可执行文件来做同样的事情。在定义字符串部分(窗口->定义字符串)我们搜索字符串ACLUI。出现了三个结果:

p.5_graphic_6_.png

然后,我们遵循对字符串ACLUI.DLL的引用,并最终完成对LoadLibraryW的调用:

p.5_graphic_7_.png

我们观察到LoadLibraryW API的参数不是完整路径,因此我们确认应用了DLL搜索顺序。

如果我们创建一个有效载荷DLL,将其放置在与可执行文件相同的目录中,然后运行该可执行文件,则会显示以下消息框:

p.5_graphic_8_.png

这意味着可执行文件从我们的有效载荷DLL请求一个不存在的函数,为了允许我们的有效载荷从应用程序执行,我们必须导出函数EditSecurity。以下屏幕快照显示了使用C / C ++代码执行此操作的方法:

p.5_graphic_9_.png

自动化DLL搜索顺序

就像我们对GoogleCrashHandler图像所做的一样,我们创建了一个自定义DLL,该DLL执行从CobaltStrike生成的beacon shellcode。我们将输出DLL命名为ACLUI.DLL,并将其放置在与OleView.exe可执行映像相同的目录中。然后,我们打开OleView。下一张图片显示恶意DLL被映射到OleView的地址空间中并启动了一个信标。

p.6_graphic_10_.png

缓解策略

基于我们所观察到的事件以及过去如何滥用DLL搜索顺序,我们可以推荐在这些环境中应用的特定最佳实践。这些建议旨在减少攻击面,限制潜在攻击的后果,并减少检测相关攻击所需的时间。

通常建议公司在其环境中部署功能和策略,作为功能的一部分,强烈建议部署事件检测和响应(EDR)软件。在策略方面,填充和维护授权在该环境中运行的所有应用程序的列表,并实现应用程序白名单,以防止不属于该列表的应用程序运行,这是一个很好的实践。为了检测流氓DLL,建议对环境中观察到的DLL进行频率分析。DLL的低频发生可能是值得进一步分析的指标。可以防止其他DLL劫持攻击的另一件事是启用SafeDllSearchMode并在系统上配置CWDIllegalInDLLSearch注册表。

软件开发人员也必须遵循最佳实践,例如,当应用程序在运行时加载模块时,建议为提供给LoadLibrary和LoadLibraryEx API的模块指定绝对路径,或使用API SetDllDirectory专门设置Windows加载器将从中加载提供的模块的路径。这样,就不会查找正常的搜索顺序。根据最佳实践,另一项建议是通过“应用程序清单”对加载的模块实施完整性检查。通过这样做,应用程序将防止恶意DLL的加载,并有可能将识别出的异常通知用户。

DLLHSC简介

DLLHSC是一个应用程序,旨在自动扫描提供的可执行映像,生成潜在顾客(以后可以手动评估)并报告利用DLL搜索顺序的潜在路径,最终目的是在地址空间中加载有效载荷DLL。通过搜索顺序劫持提供的图像。

操作模式

该工具实现3种操作模式,如下所述。

轻量级的模式

在内存中加载可执行映像,解析导入表,然后用有效载荷DLL替换导入表中引用的任何DLL。该工具将一个模块(DLL)放在应用程序目录中,该模块不存在于应用程序目录中,不属于WinSxS,也不属于KnownDLLs。

然后,它启动应用程序并报告是否执行了有效载荷DLL。有效载荷DLL在执行后会在路径C:\ Users \%USERNAME%\ AppData \ Local \ Temp \ DLLHSC.tmp中创建一个临时文件。如果临时文件存在,则表明扫描的应用程序可能被滥用。当某些可执行文件从它们加载的DLL导入函数时,当提供的DLL无法导出这些函数并因此满足提供的映像的依赖性时,可能会显示错误消息框。

但是,消息框表明,如果满足依赖关系,DLL可能是有效载荷执行的好候选对象。在这种情况下,需要进行额外的分析。这些消息框的标题可能包含以下字符串:“找不到常规”或“找不到入口点”。 DLLHSC会查找包含这些字符串的窗口,并在出现这些窗口时立即关闭它们并报告结果。

模块列表模式

使用提供的可执行映像创建一个进程,枚举此进程的地址空间中加载的模块,并在应用过滤器后报告结果。

该工具仅报告从系统目录加载的模块,不属于KnownDLL。结果是需要进一步分析的线索。然后,分析人员可以将报告的模块放在应用程序目录中,并检查应用程序是否加载了提供的模块。

运行模式

通过Microsoft Detours(Detours是微软开发的一个函数库,可用于捕获系统API)挂钩LoadLibrary和LoadLibraryEx API时,并报告在运行时加载的模块。

每次扫描的应用程序调用LoadLibrary和LoadLibraryEx时,该工具都会拦截该调用,并将请求的模块写入文件C:\Users\%USERNAME%\AppData\Local\Temp\DLLHSCRTLOG.tmp中。如果使用标志LOAD_LIBRARY_SEARCH_SYSTEM32专门调用LoadLibraryEx,则不会将任何输出写入文件。完成所有拦截之后,该工具将读取文件并打印结果。对于进一步的分析,我们感兴趣的是KnownDLLs注册表键中不存在的模块、系统目录中不存在的模块以及没有完整路径的模块(对于这些模块,加载器应用正常的搜索顺序)。

你可以在我们的GitHub页面上找到DLLHSC的源代码以及x86和x64体系结构的编译二进制文件。

01.png

几年以来,我们作为渗透测试者大量使用NTLM来实现Windows网络中的特权升级。

在本文中,我们建议将对RPC协议的支持添加到已经很强大的 impacket 库的 ntlmrelayx中,并探索它提供的新的攻击方法。

利用CVE-2020-1113

由于没有针对RPC协议的全局完整性验证要求,中间人攻击者可以将受害人的NTLM身份验证中继到通过RPC协议选择的目标。如果受害者在目标上具有管理特权,则攻击者可以在远程目标上执行代码。这种攻击在一个完全打了补丁的Windows Server 2016域控制器上进行了测试,该漏洞于2020年1月被Compass Security发现,并向Microsoft安全响应中心披露了该漏洞,并将其分配为CVE-2020-1113作为标识符。

https://portal.msrc.microsoft.com/zh-CN/security-guidance/advisory/CVE-2020-1113

Microsoft在2020年5月星期二的更新中发布了此修复程序,所实现的解决方案为任务调度器服务添加了完整性要求,它不能解决RPC缺少全局完整性要求的漏洞。

NTLM中继101

下图给出了NTLM中继攻击的简化视图:

1.gif

攻击者充当客户端的服务器,并充当服务器的客户端。他从客户端消息中提取NTLM身份验证Blob,并将其放入服务器的修改后的消息中,反之亦然。最后,他可以根据需要使用经过身份验证的会话。

为了使这种攻击奏效,必须处于中间人的位置。攻击者可以使用传统的欺骗技术(ARP,DNS,LLMNR和Netbios等)来实现,也可以通过漏洞或滥用功能(打印机漏洞,Juicy Potato等)触发与攻击者计算机的连接来实现。

NTLM中继已在多种攻击中使用和重用过:

打印机漏洞:一种从Windows Server触发SMB连接的好方法(与无约束的委托结合起来特别方便);

PrivExchange:如何从任何用户的交换邮箱升级到域管理员;

断开MIC:如何绕过完全保护继电器;

这些攻击中继了以下协议:

SMB→SMB(打印机漏洞)

HTTP→LDAP(PrivExchange)

SMB→LDAPS(删除MIC)

RPC的一些背景

定义

1. 远程过程调用(RPC)是指一个程序在不同的地址空间(例如在不同的计算机上)执行一个过程;

2. DCE / RPC是由Open Group设计的RPC协议标准;

3. MSRPC(又名MS-RPCE)是微软DCE/RPC的修改版本。

但是RPC仍在继续被人使用

那就是越来越有趣的地方,RPC用于远程系统管理。WMI基于DCOM,该DCOM使用RPC作为传输方式(有时通过SMB):

1. 监控和远程管理工具支持WMI(快速搜索将提供例如Solarwinds,NetCrunch,PRTG,LanSweeper,Kaseya等),并且必须配置特权服务帐户。

2.png

此监控解决方案需要具有管理权限的凭据,编辑者甚至指出:“可以使用域管理员。”这似乎很危险,因为此帐户将尝试连接到网络中的所有主机。

2. 系统管理员还可以使用WMI手动执行远程任务,可能使用特权帐户。

3.png

默认情况下,RPC用于Windows防火墙,因为它用于远程管理。

认证和完整性

安全服务提供商

依赖RPC的工具使用标准Windows安全提供程序进行身份验证,可能有以下值:

4.png

请注意,默认值为WINNT,这意味着NTLM身份验证听起来不错。

认证等级

身份验证级别设置RPC交换中是否存在身份验证和完整性检查:

5.png

再次注意,默认值为CONNECT,这意味着不进行完整性检查。

幸运的是,大多数基于RPC的协议都具有最低的安全要求:

MS-SAMR:服务器SHOULD。

MS-LSAD:请求者不得使用RPC提供的安全支持提供程序机制,用于身份验证、授权、机密性或抗篡改服务。

不幸的是,其他一些具有较少的限制性要求:

MS-DCOM:服务器SHOULD 注册[MS-RPCE] 2.2.1.1.7节中指定的一个或多个安全提供程序,安全服务提供商的选择取决于实现。

MS-TSCH:RPC服务器MUST 要求RPC_C_AUTHN_GSS_NEGOTIATE或RPC_C_AUTHN_WINNT授权。 RPC客户端必须使用[MS-RPCE] 2.2.1.1.8节中指定的RPC_C_AUTHN_LEVEL_PKT_PRIVACY(值= 6)身份验证级别。

发起攻击

MS-DCOM被MS-WMI使用,是一个很好的攻击载体。但是,由于典型的WMI代码执行需要对多个RPC接口进行身份验证,因此,它不是NTLM中继攻击(没有重新身份验证方法)的最佳选择。

MS-TSCH是用于管理计划任务的协议,它在atexecute .py中使用。这是否意味着我们可以中继NTLM身份验证并使用计划的任务执行代码?

impacket修改版本包括以下三个新组件:

· RPCRelayServer响应传入的RPC连接;

· RPCRelayClient启动到目标的RPC连接;

· RPCAttack(基于ATExec)在目标上执行代码。

PoC或GTFO

在我们的设置中,攻击者计算机的IP为172.16.100.21,目标计算机DC是具有最新补丁程序版本的Windows Server 2016,并且IP为172.16.100.1。受害用户WINLAB \ scooper-da在DC计算机的本地Administrators组中,并从IP为172.16.100.14的计算机打开SMB连接。

信息披露开发人员编写了许多应用程序,他们无法抗拒将敏感信息存储在文件系统和/或注册表中的甜美警报。其中包括社会保险号,信用卡号,数据库连接字符串,凭据等。开发人员可以对数据进行加密,以增强安全感,但是可能存在不安全或自定义的加密实现。如果必须存储加密数据,则必须始终将密钥存储在单独的位置,例如安全地存储在数据库中。

集中测试测试文件系统和注册表中的信息泄露非常简单,你只需要查看应用程序使用的文件和注册表项,并确保其中没有任何敏感信息。但是应用程序经常对文件和注册表项进行疯狂的调用。这就是为什么将重点放在最可能写入或读取敏感数据的应用程序区域上的原因。

安装程序如果可以测试安装,请始终以此为契机查找对文件系统或注册表的写入。现在是写入数据的最佳时机,稍后应用程序将读取该数据。该应用程序将连接到数据库吗?也许安装过程将数据库连接字符串写入注册表项。也许默认的管理员凭据存储在文件系统中。

应用程序在实际应用程序中,识别可能创建或修改敏感信息的功能区域。这通常包括初始数据库连接和登录表单。许多应用程序都为“记住我”功能保存了一些信息,因此请确定如何存储和检索这些信息。在应用程序的经过身份验证的部分中,查找专门处理敏感数据的区域。

工具和示例Sysinternals套件包含许多用于测试Windows应用程序的有用工具,我将重点介绍的两个工具是AccessEnum和Process Monitor,它们是由Microsoft Azure的CTO编写的。我将重点介绍的易受攻击的应用程序是BetaFast。配置Process Monitor将尝试向你显示比你想象的更多的信息,因此第一步是设置过滤器。 Process Monitor可以过滤的一项是你正在测试的应用程序的PID,因此请务必在任务管理器中进行检查。敏感数据,例如身份证号码或医疗信息,是否以明文传输?有一次,我以用户名“blogger”向应用程序进行了身份验证。在Wireshark中搜索包列表时,“blogger”的名称出现在登录过程中。这甚至是远程可读的,这意味着数据库连接是未加密的,任何访问此网络的人都可以轻松地读取此信息。幸运的是,密码似乎是加密的,所以黑客将无法访问我的帐户。从客户端发送的任何形式的密码,无论是明文、散列还是加密的,都应该是密码本身。当然,密码是加密的。但是,知道这个值并将其发送给服务器,就可以向应用程序验证该用户的身份。仅模糊参数值和不安全加密整个传输不会提供额外的防御。通过wireshark观察到的另一个值是登录过程的输出参数GUID。在应用程序的经过身份验证的部分中,接受GUID作为参数。

攻击者启动ntlmrelayx.py

攻击者将安装我们的自定义版本的impacket,并在其IP为172.16.100.21的主机上启动该工具。他想在目标172.16.100.1上添加本地管理员(名为compass):

6.png

受害者触发连接

受害人从计算机172.16.100.14打开与攻击者计算机的SMB连接,这模仿了管理员使用前面提到的工具之一访问共享或执行管理任务:

7.png

该工具将拾取连接并进行中继,由于中继用户是目标计算机上的本地管理员,因此他有权添加我们的新管理员:

8.png

结果,将创建一个新用户并将其添加到本地Administrators组。

中继性能

我们测试了以下方案:

9.png

服务器端的SMB签名(在我们的测试中设置为必需,如默认的DC安装一样)可防止从RPC中继到SMB。在客户端,默认情况下不需要SMB签名,这可以成功中继到RPC。

一些有趣的用例

滥用用户帐户

最小特权是安全专业人员的一个梦想,但并不容易实现,管理员将高特权帐户用于各种用途。

RPC→RPC:从监控工具获得连接,并在其他主机上获得管理员访问权限。

10.png

滥用计算机帐户

有时(通常是在旧的Exchange服务器上),一个计算机帐户是另一台计算机的管理员。

微信截图_20200616154303.png

此BloodHound捕获展示了一个非常常见的场景,其中一台设备对其他设备进行管理。

RPC→RPC:你在受害计算机上具有低特权会话,可以使用RottenPotato触发与攻击者计算机的RPC连接并将其中继到目标。

SMB→RPC:受害者计算机已激活后台处理程序服务,你可以使用打印机漏洞触发与攻击者计算机的SMB连接,并将其中继到目标。

编码

我们将于6月中旬将对impacket的修改推送到以下GitHub存储库:

https://github.com/CompassSecurity/impacket

缓解措施

此攻击依赖于几个漏洞,CVE-2020-1113只是其中之一。以下是一些解决潜在漏洞的措施:

1. 修补你的Windows!

2. 通过GPO对整个网络中的客户端和服务器强制执行数据包签名;

3. 检查你的Active Directory ACL:应该使用最小特权原则;

4. 网络分割可以帮助防止中继攻击;

5. 立即停止使用NTLM。

以下思路可以提高ntlmrelayx对RPC的支持:

1. 支持会话重用:RPC攻击目前只是一种攻击,无法像SMB一样通过socks代理保存和重用会话。

2. 开发更多的RPC攻击:使用未经分析的MS-DCOM,MS-WMI或其他协议,有可能使攻击范围脱离对CVE-2020-1113的依赖。

3. 支持更多的RPC接口:某些客户端将在身份验证之前执行未经身份验证的RPC调用,目前PoC只支持IID_IObjectExporter接口(99FCFEC4-5260-101B-BBCB-00AA0021347A)。

可以找到其他向量来获得传入的RPC连接:

远程Juicy Potato(Windows特权模拟工具,已经在攻防安全社区中非常流行):找到类似于“打印机漏洞”的漏洞,这将触发通过RPC远程验证给定主机的调用,这将是很有趣的。

01.png

几年以来,我们作为渗透测试者大量使用NTLM来实现Windows网络中的特权升级。

在本文中,我们建议将对RPC协议的支持添加到已经很强大的 impacket 库的 ntlmrelayx中,并探索它提供的新的攻击方法。

利用CVE-2020-1113

由于没有针对RPC协议的全局完整性验证要求,中间人攻击者可以将受害人的NTLM身份验证中继到通过RPC协议选择的目标。如果受害者在目标上具有管理特权,则攻击者可以在远程目标上执行代码。这种攻击在一个完全打了补丁的Windows Server 2016域控制器上进行了测试,该漏洞于2020年1月被Compass Security发现,并向Microsoft安全响应中心披露了该漏洞,并将其分配为CVE-2020-1113作为标识符。

https://portal.msrc.microsoft.com/zh-CN/security-guidance/advisory/CVE-2020-1113

Microsoft在2020年5月星期二的更新中发布了此修复程序,所实现的解决方案为任务调度器服务添加了完整性要求,它不能解决RPC缺少全局完整性要求的漏洞。

NTLM中继101

下图给出了NTLM中继攻击的简化视图:

1.gif

攻击者充当客户端的服务器,并充当服务器的客户端。他从客户端消息中提取NTLM身份验证Blob,并将其放入服务器的修改后的消息中,反之亦然。最后,他可以根据需要使用经过身份验证的会话。

为了使这种攻击奏效,必须处于中间人的位置。攻击者可以使用传统的欺骗技术(ARP,DNS,LLMNR和Netbios等)来实现,也可以通过漏洞或滥用功能(打印机漏洞,Juicy Potato等)触发与攻击者计算机的连接来实现。

NTLM中继已在多种攻击中使用和重用过:

打印机漏洞:一种从Windows Server触发SMB连接的好方法(与无约束的委托结合起来特别方便);

PrivExchange:如何从任何用户的交换邮箱升级到域管理员;

断开MIC:如何绕过完全保护继电器;

这些攻击中继了以下协议:

SMB→SMB(打印机漏洞)

HTTP→LDAP(PrivExchange)

SMB→LDAPS(删除MIC)

RPC的一些背景

定义

1. 远程过程调用(RPC)是指一个程序在不同的地址空间(例如在不同的计算机上)执行一个过程;

2. DCE / RPC是由Open Group设计的RPC协议标准;

3. MSRPC(又名MS-RPCE)是微软DCE/RPC的修改版本。

但是RPC仍在继续被人使用

那就是越来越有趣的地方,RPC用于远程系统管理。WMI基于DCOM,该DCOM使用RPC作为传输方式(有时通过SMB):

1. 监控和远程管理工具支持WMI(快速搜索将提供例如Solarwinds,NetCrunch,PRTG,LanSweeper,Kaseya等),并且必须配置特权服务帐户。

2.png

此监控解决方案需要具有管理权限的凭据,编辑者甚至指出:“可以使用域管理员。”这似乎很危险,因为此帐户将尝试连接到网络中的所有主机。

2. 系统管理员还可以使用WMI手动执行远程任务,可能使用特权帐户。

3.png

默认情况下,RPC用于Windows防火墙,因为它用于远程管理。

认证和完整性

安全服务提供商

依赖RPC的工具使用标准Windows安全提供程序进行身份验证,可能有以下值:

4.png

请注意,默认值为WINNT,这意味着NTLM身份验证听起来不错。

认证等级

身份验证级别设置RPC交换中是否存在身份验证和完整性检查:

5.png

再次注意,默认值为CONNECT,这意味着不进行完整性检查。

幸运的是,大多数基于RPC的协议都具有最低的安全要求:

MS-SAMR:服务器SHOULD。

MS-LSAD:请求者不得使用RPC提供的安全支持提供程序机制,用于身份验证、授权、机密性或抗篡改服务。

不幸的是,其他一些具有较少的限制性要求:

MS-DCOM:服务器SHOULD 注册[MS-RPCE] 2.2.1.1.7节中指定的一个或多个安全提供程序,安全服务提供商的选择取决于实现。

MS-TSCH:RPC服务器MUST 要求RPC_C_AUTHN_GSS_NEGOTIATE或RPC_C_AUTHN_WINNT授权。 RPC客户端必须使用[MS-RPCE] 2.2.1.1.8节中指定的RPC_C_AUTHN_LEVEL_PKT_PRIVACY(值= 6)身份验证级别。

发起攻击

MS-DCOM被MS-WMI使用,是一个很好的攻击载体。但是,由于典型的WMI代码执行需要对多个RPC接口进行身份验证,因此,它不是NTLM中继攻击(没有重新身份验证方法)的最佳选择。

MS-TSCH是用于管理计划任务的协议,它在atexecute .py中使用。这是否意味着我们可以中继NTLM身份验证并使用计划的任务执行代码?

impacket修改版本包括以下三个新组件:

· RPCRelayServer响应传入的RPC连接;

· RPCRelayClient启动到目标的RPC连接;

· RPCAttack(基于ATExec)在目标上执行代码。

PoC或GTFO

在我们的设置中,攻击者计算机的IP为172.16.100.21,目标计算机DC是具有最新补丁程序版本的Windows Server 2016,并且IP为172.16.100.1。受害用户WINLAB \ scooper-da在DC计算机的本地Administrators组中,并从IP为172.16.100.14的计算机打开SMB连接。

信息披露开发人员编写了许多应用程序,他们无法抗拒将敏感信息存储在文件系统和/或注册表中的甜美警报。其中包括社会保险号,信用卡号,数据库连接字符串,凭据等。开发人员可以对数据进行加密,以增强安全感,但是可能存在不安全或自定义的加密实现。如果必须存储加密数据,则必须始终将密钥存储在单独的位置,例如安全地存储在数据库中。

集中测试测试文件系统和注册表中的信息泄露非常简单,你只需要查看应用程序使用的文件和注册表项,并确保其中没有任何敏感信息。但是应用程序经常对文件和注册表项进行疯狂的调用。这就是为什么将重点放在最可能写入或读取敏感数据的应用程序区域上的原因。

安装程序如果可以测试安装,请始终以此为契机查找对文件系统或注册表的写入。现在是写入数据的最佳时机,稍后应用程序将读取该数据。该应用程序将连接到数据库吗?也许安装过程将数据库连接字符串写入注册表项。也许默认的管理员凭据存储在文件系统中。

应用程序在实际应用程序中,识别可能创建或修改敏感信息的功能区域。这通常包括初始数据库连接和登录表单。许多应用程序都为“记住我”功能保存了一些信息,因此请确定如何存储和检索这些信息。在应用程序的经过身份验证的部分中,查找专门处理敏感数据的区域。

工具和示例Sysinternals套件包含许多用于测试Windows应用程序的有用工具,我将重点介绍的两个工具是AccessEnum和Process Monitor,它们是由Microsoft Azure的CTO编写的。我将重点介绍的易受攻击的应用程序是BetaFast。配置Process Monitor将尝试向你显示比你想象的更多的信息,因此第一步是设置过滤器。 Process Monitor可以过滤的一项是你正在测试的应用程序的PID,因此请务必在任务管理器中进行检查。敏感数据,例如身份证号码或医疗信息,是否以明文传输?有一次,我以用户名“blogger”向应用程序进行了身份验证。在Wireshark中搜索包列表时,“blogger”的名称出现在登录过程中。这甚至是远程可读的,这意味着数据库连接是未加密的,任何访问此网络的人都可以轻松地读取此信息。幸运的是,密码似乎是加密的,所以黑客将无法访问我的帐户。从客户端发送的任何形式的密码,无论是明文、散列还是加密的,都应该是密码本身。当然,密码是加密的。但是,知道这个值并将其发送给服务器,就可以向应用程序验证该用户的身份。仅模糊参数值和不安全加密整个传输不会提供额外的防御。通过wireshark观察到的另一个值是登录过程的输出参数GUID。在应用程序的经过身份验证的部分中,接受GUID作为参数。

攻击者启动ntlmrelayx.py

攻击者将安装我们的自定义版本的impacket,并在其IP为172.16.100.21的主机上启动该工具。他想在目标172.16.100.1上添加本地管理员(名为compass):

6.png

受害者触发连接

受害人从计算机172.16.100.14打开与攻击者计算机的SMB连接,这模仿了管理员使用前面提到的工具之一访问共享或执行管理任务:

7.png

该工具将拾取连接并进行中继,由于中继用户是目标计算机上的本地管理员,因此他有权添加我们的新管理员:

8.png

结果,将创建一个新用户并将其添加到本地Administrators组。

中继性能

我们测试了以下方案:

9.png

服务器端的SMB签名(在我们的测试中设置为必需,如默认的DC安装一样)可防止从RPC中继到SMB。在客户端,默认情况下不需要SMB签名,这可以成功中继到RPC。

一些有趣的用例

滥用用户帐户

最小特权是安全专业人员的一个梦想,但并不容易实现,管理员将高特权帐户用于各种用途。

RPC→RPC:从监控工具获得连接,并在其他主机上获得管理员访问权限。

10.png

滥用计算机帐户

有时(通常是在旧的Exchange服务器上),一个计算机帐户是另一台计算机的管理员。

微信截图_20200616154303.png

此BloodHound捕获展示了一个非常常见的场景,其中一台设备对其他设备进行管理。

RPC→RPC:你在受害计算机上具有低特权会话,可以使用RottenPotato触发与攻击者计算机的RPC连接并将其中继到目标。

SMB→RPC:受害者计算机已激活后台处理程序服务,你可以使用打印机漏洞触发与攻击者计算机的SMB连接,并将其中继到目标。

编码

我们将于6月中旬将对impacket的修改推送到以下GitHub存储库:

https://github.com/CompassSecurity/impacket

缓解措施

此攻击依赖于几个漏洞,CVE-2020-1113只是其中之一。以下是一些解决潜在漏洞的措施:

1. 修补你的Windows!

2. 通过GPO对整个网络中的客户端和服务器强制执行数据包签名;

3. 检查你的Active Directory ACL:应该使用最小特权原则;

4. 网络分割可以帮助防止中继攻击;

5. 立即停止使用NTLM。

以下思路可以提高ntlmrelayx对RPC的支持:

1. 支持会话重用:RPC攻击目前只是一种攻击,无法像SMB一样通过socks代理保存和重用会话。

2. 开发更多的RPC攻击:使用未经分析的MS-DCOM,MS-WMI或其他协议,有可能使攻击范围脱离对CVE-2020-1113的依赖。

3. 支持更多的RPC接口:某些客户端将在身份验证之前执行未经身份验证的RPC调用,目前PoC只支持IID_IObjectExporter接口(99FCFEC4-5260-101B-BBCB-00AA0021347A)。

可以找到其他向量来获得传入的RPC连接:

远程Juicy Potato(Windows特权模拟工具,已经在攻防安全社区中非常流行):找到类似于“打印机漏洞”的漏洞,这将触发通过RPC远程验证给定主机的调用,这将是很有趣的。

Apple-TV-apple-watch-iphone_1200x630.jpg

你如何才能从iPhone,iPad,Apple TV或Apple Watch获得大量有价值的数据呢?这并不像看起来那么简单。目前存在多种相似的提取方法,其中某些方法仅限于特定版本的操作系统。本文,我们就从兼容性角度,对比一下iOS,watchOS和tvOS的取证方法。

兼容性比较

兼容性通常取决于iOS/iPadOS(同步)的版本和SoC模型。注意:FFS(full file system)代表“完整文件系统”。

Infographics-2-v.0.2-1536x594.png

按设备类型比较

iPhone和iPad(iOS/iPadOS)

多种取证方法均可以在装有iOS和iPadOS的系统上使用,你只需要一根Lightning或iPad Pro的USB Type-C线。但是,对于用checkra1n进行采集,我们建议使用USB-A到Lightning,但不建议使用USB-C到Lightning,因为它可能会出现问题,尤其是在使设备进入DFU模式时。

苹果电视(tvOS)

对于Apple TV 4,由于配备了USB Type-C端口,因此不需要任何额外的操作。对于4K型号,需要一条特殊的电缆连接到隐藏的Lightning端口。有关详细信息,请见《如何对Apple TV 4K越狱》

如果你希望使用checkra1n而不是unc0ver越狱(例如,当tvOS版本与unc0ver不兼容时),请注意,仅使用适配器是不够的。你还需要一根特殊的数据线才能使设备进入DFU模式。

这样,无需越狱,你就可以提取媒体文件和元数据以及一些诊断日志。

苹果手表(watchOS)

这是你始终需要适配器的系统,有关详细信息,请参阅《Apple TV和Apple Watch Forensics 01取证》。 记得,关键是IBUS。目前,适配器仅适用于S1 / S2 / S3手表,而不适用于S4和S5。与此同时,手表收集的一些数据(大部分是健康数据)会同步到iCloud(通过它所连接的iPhone)。完整的Watch备份不可用,但是iPhone备份中还提供了一些Watch数据。

获取方法比较

逻辑采集是最快,最简单,最安全和最兼容的采集方法,即使它仅提供有限数量的数据,它仍然是尝试的第一种方法。但是仍然有一些事情要注意:

1.本地备份和iCloud备份的内容有所不同;

2.使用密码和不使用密码的本地备份之间也存在差异(请参阅有关iPhone备份的最不寻常的事情);受密码保护的备份包含更多数据。

3.云备份通常很难获得,这不仅仅是双因素身份验证的问题。

接下来,请记住备份只是逻辑获取的一部分。即使备份受密码保护并且密码未知,你也可以提取媒体文件以及元数据。此外,你可以提取一些共享文件(通常是文档,有时还包括从图像到数据库的其他用户数据)和诊断日志,这可能有助于建立设备使用时间表。此方法是唯一可在非越狱Apple TV以及Apple Watch S1至S3设备上使用的方法。

完整的文件系统映像当然比备份好得多,甚至还可以使用媒体提取进行补充。使用文件系统映像,你可以从设备上获取所有信息,包括沙盒应用程序数据和具有多个记录的位置点,使用信息以及许多其他内容的系统数据库。

在取证当中,获取钥匙串是关键,钥匙串存储了用户的所有密码、加密密钥、证书、信用卡数据等。通过获取和解密钥匙串,你将能够解密来自那些号称最安全的聊天程序的聊天记录,访问设备所有者使用的其他云服务,以及执行更多操作。如果你不提取钥匙串,你就失去了可靠的证据。

要获得文件系统和密钥链,我们建议使用代理获取方法(如果兼容的话),因为这是最安全、最可靠的方法。但是,iOS版本和具有越狱功能的设备模型的支持范围略广。

最后,是对iCloud的取证。这种方法有很多优点,我们在以前已经介绍过多次。比如,无需手持设备,你就可以访问已从设备中删除的当前和以前的数据集。你可以从与同一账户相连的其他设备上获取一些其他数据,愿意的话,你还可以执行更多操作。

操作系统版本

对于逻辑获取,包括媒体文件和日志的提取,系统版本根本不重要。我们可以为所有的操作系统版本做到这一点,从古老的iOS 4到尚未发布的iOS 13.6测试版(撰写本文时的最新版本);结果大致相同。iOS 14的第一个测试版将于下周发布,几乎可以肯定,我们将能够从一开始就对其进行逻辑采集。

对于基于越狱的信息取证以及与我们的代理人进行的信息取证,我们不能采取相同的办法,这些方法取决于漏洞利用的可用性。它们确实存在于包括iOS 13.5(包括iOS 13.5)在内的大多数iOS版本中,但某些特定版本并未完全涵盖。例如,对于iPhone 5s和iPhone 6设备以及运行iOS 13.3.1至13.4.1的任何设备,我们只能提取文件系统,而不能提取iOS 12.3至12.4.7的钥匙串。最后,虽然iOS 13.5可以使用越狱功能,以获取文件系统和钥匙串,但你必须自己越狱,但你必须自己去越狱,代理不会帮忙的。对于iOS 13.5.1至13.6 beta 2,可以使用checkra1n(仅适用于兼容型号)。

对于tvOS,信息取证就困难重重了。存在类似的漏洞利用,但是越狱仅适用于tvOS 9- tvOS 12,范围非常有限的版本。只有tvOS 13可以对checkra1n越狱完全开放,理论上包括最新的13.4.8 beta,不过我们尚未对其进行测试。将来我们可能会为较旧的tvOS版本开发基于代理的获取,但目前尚无安全加密流量分析 (ETA) 。同时,Apple默认情况下会自动更新tvOS,因此用户的Apple TV将正常运行最新版本的tvOS。

至于watchOS,无论watchOS版本如何,都无需考虑文件系统的获取。watchOS很容易受到checkm8攻击,但是,没有适用于watchOS 5.2和更高版本的公开越狱(当前版本为watchOS 6.2.8 beta 2)。另一方面,Apple Watch收集的大多数信息都可以从与其配对的iPhone或从icloud中获得。但是,如果你具有IBUS适配器,则可以提取媒体文件和元数据(对于S1-S3系列手表)。

总结

正如我们之前所写的,在分析苹果设备时,并没有“一键解决方案”,尽管我们试图使工作流程尽可能简单。重要的是要了解硬件和软件的各种特性,并在选择提取方法时做出明智的信息取证方案。

Apple-TV-apple-watch-iphone_1200x630.jpg

你如何才能从iPhone,iPad,Apple TV或Apple Watch获得大量有价值的数据呢?这并不像看起来那么简单。目前存在多种相似的提取方法,其中某些方法仅限于特定版本的操作系统。本文,我们就从兼容性角度,对比一下iOS,watchOS和tvOS的取证方法。

兼容性比较

兼容性通常取决于iOS/iPadOS(同步)的版本和SoC模型。注意:FFS(full file system)代表“完整文件系统”。

Infographics-2-v.0.2-1536x594.png

按设备类型比较

iPhone和iPad(iOS/iPadOS)

多种取证方法均可以在装有iOS和iPadOS的系统上使用,你只需要一根Lightning或iPad Pro的USB Type-C线。但是,对于用checkra1n进行采集,我们建议使用USB-A到Lightning,但不建议使用USB-C到Lightning,因为它可能会出现问题,尤其是在使设备进入DFU模式时。

苹果电视(tvOS)

对于Apple TV 4,由于配备了USB Type-C端口,因此不需要任何额外的操作。对于4K型号,需要一条特殊的电缆连接到隐藏的Lightning端口。有关详细信息,请见《如何对Apple TV 4K越狱》

如果你希望使用checkra1n而不是unc0ver越狱(例如,当tvOS版本与unc0ver不兼容时),请注意,仅使用适配器是不够的。你还需要一根特殊的数据线才能使设备进入DFU模式。

这样,无需越狱,你就可以提取媒体文件和元数据以及一些诊断日志。

苹果手表(watchOS)

这是你始终需要适配器的系统,有关详细信息,请参阅《Apple TV和Apple Watch Forensics 01取证》。 记得,关键是IBUS。目前,适配器仅适用于S1 / S2 / S3手表,而不适用于S4和S5。与此同时,手表收集的一些数据(大部分是健康数据)会同步到iCloud(通过它所连接的iPhone)。完整的Watch备份不可用,但是iPhone备份中还提供了一些Watch数据。

获取方法比较

逻辑采集是最快,最简单,最安全和最兼容的采集方法,即使它仅提供有限数量的数据,它仍然是尝试的第一种方法。但是仍然有一些事情要注意:

1.本地备份和iCloud备份的内容有所不同;

2.使用密码和不使用密码的本地备份之间也存在差异(请参阅有关iPhone备份的最不寻常的事情);受密码保护的备份包含更多数据。

3.云备份通常很难获得,这不仅仅是双因素身份验证的问题。

接下来,请记住备份只是逻辑获取的一部分。即使备份受密码保护并且密码未知,你也可以提取媒体文件以及元数据。此外,你可以提取一些共享文件(通常是文档,有时还包括从图像到数据库的其他用户数据)和诊断日志,这可能有助于建立设备使用时间表。此方法是唯一可在非越狱Apple TV以及Apple Watch S1至S3设备上使用的方法。

完整的文件系统映像当然比备份好得多,甚至还可以使用媒体提取进行补充。使用文件系统映像,你可以从设备上获取所有信息,包括沙盒应用程序数据和具有多个记录的位置点,使用信息以及许多其他内容的系统数据库。

在取证当中,获取钥匙串是关键,钥匙串存储了用户的所有密码、加密密钥、证书、信用卡数据等。通过获取和解密钥匙串,你将能够解密来自那些号称最安全的聊天程序的聊天记录,访问设备所有者使用的其他云服务,以及执行更多操作。如果你不提取钥匙串,你就失去了可靠的证据。

要获得文件系统和密钥链,我们建议使用代理获取方法(如果兼容的话),因为这是最安全、最可靠的方法。但是,iOS版本和具有越狱功能的设备模型的支持范围略广。

最后,是对iCloud的取证。这种方法有很多优点,我们在以前已经介绍过多次。比如,无需手持设备,你就可以访问已从设备中删除的当前和以前的数据集。你可以从与同一账户相连的其他设备上获取一些其他数据,愿意的话,你还可以执行更多操作。

操作系统版本

对于逻辑获取,包括媒体文件和日志的提取,系统版本根本不重要。我们可以为所有的操作系统版本做到这一点,从古老的iOS 4到尚未发布的iOS 13.6测试版(撰写本文时的最新版本);结果大致相同。iOS 14的第一个测试版将于下周发布,几乎可以肯定,我们将能够从一开始就对其进行逻辑采集。

对于基于越狱的信息取证以及与我们的代理人进行的信息取证,我们不能采取相同的办法,这些方法取决于漏洞利用的可用性。它们确实存在于包括iOS 13.5(包括iOS 13.5)在内的大多数iOS版本中,但某些特定版本并未完全涵盖。例如,对于iPhone 5s和iPhone 6设备以及运行iOS 13.3.1至13.4.1的任何设备,我们只能提取文件系统,而不能提取iOS 12.3至12.4.7的钥匙串。最后,虽然iOS 13.5可以使用越狱功能,以获取文件系统和钥匙串,但你必须自己越狱,但你必须自己去越狱,代理不会帮忙的。对于iOS 13.5.1至13.6 beta 2,可以使用checkra1n(仅适用于兼容型号)。

对于tvOS,信息取证就困难重重了。存在类似的漏洞利用,但是越狱仅适用于tvOS 9- tvOS 12,范围非常有限的版本。只有tvOS 13可以对checkra1n越狱完全开放,理论上包括最新的13.4.8 beta,不过我们尚未对其进行测试。将来我们可能会为较旧的tvOS版本开发基于代理的获取,但目前尚无安全加密流量分析 (ETA) 。同时,Apple默认情况下会自动更新tvOS,因此用户的Apple TV将正常运行最新版本的tvOS。

至于watchOS,无论watchOS版本如何,都无需考虑文件系统的获取。watchOS很容易受到checkm8攻击,但是,没有适用于watchOS 5.2和更高版本的公开越狱(当前版本为watchOS 6.2.8 beta 2)。另一方面,Apple Watch收集的大多数信息都可以从与其配对的iPhone或从icloud中获得。但是,如果你具有IBUS适配器,则可以提取媒体文件和元数据(对于S1-S3系列手表)。

总结

正如我们之前所写的,在分析苹果设备时,并没有“一键解决方案”,尽管我们试图使工作流程尽可能简单。重要的是要了解硬件和软件的各种特性,并在选择提取方法时做出明智的信息取证方案。

Apple-TV-apple-watch-iphone_1200x630.jpg

你如何才能从iPhone,iPad,Apple TV或Apple Watch获得大量有价值的数据呢?这并不像看起来那么简单。目前存在多种相似的提取方法,其中某些方法仅限于特定版本的操作系统。本文,我们就从兼容性角度,对比一下iOS,watchOS和tvOS的取证方法。

兼容性比较

兼容性通常取决于iOS/iPadOS(同步)的版本和SoC模型。注意:FFS(full file system)代表“完整文件系统”。

Infographics-2-v.0.2-1536x594.png

按设备类型比较

iPhone和iPad(iOS/iPadOS)

多种取证方法均可以在装有iOS和iPadOS的系统上使用,你只需要一根Lightning或iPad Pro的USB Type-C线。但是,对于用checkra1n进行采集,我们建议使用USB-A到Lightning,但不建议使用USB-C到Lightning,因为它可能会出现问题,尤其是在使设备进入DFU模式时。

苹果电视(tvOS)

对于Apple TV 4,由于配备了USB Type-C端口,因此不需要任何额外的操作。对于4K型号,需要一条特殊的电缆连接到隐藏的Lightning端口。有关详细信息,请见《如何对Apple TV 4K越狱》

如果你希望使用checkra1n而不是unc0ver越狱(例如,当tvOS版本与unc0ver不兼容时),请注意,仅使用适配器是不够的。你还需要一根特殊的数据线才能使设备进入DFU模式。

这样,无需越狱,你就可以提取媒体文件和元数据以及一些诊断日志。

苹果手表(watchOS)

这是你始终需要适配器的系统,有关详细信息,请参阅《Apple TV和Apple Watch Forensics 01取证》。 记得,关键是IBUS。目前,适配器仅适用于S1 / S2 / S3手表,而不适用于S4和S5。与此同时,手表收集的一些数据(大部分是健康数据)会同步到iCloud(通过它所连接的iPhone)。完整的Watch备份不可用,但是iPhone备份中还提供了一些Watch数据。

获取方法比较

逻辑采集是最快,最简单,最安全和最兼容的采集方法,即使它仅提供有限数量的数据,它仍然是尝试的第一种方法。但是仍然有一些事情要注意:

1.本地备份和iCloud备份的内容有所不同;

2.使用密码和不使用密码的本地备份之间也存在差异(请参阅有关iPhone备份的最不寻常的事情);受密码保护的备份包含更多数据。

3.云备份通常很难获得,这不仅仅是双因素身份验证的问题。

接下来,请记住备份只是逻辑获取的一部分。即使备份受密码保护并且密码未知,你也可以提取媒体文件以及元数据。此外,你可以提取一些共享文件(通常是文档,有时还包括从图像到数据库的其他用户数据)和诊断日志,这可能有助于建立设备使用时间表。此方法是唯一可在非越狱Apple TV以及Apple Watch S1至S3设备上使用的方法。

完整的文件系统映像当然比备份好得多,甚至还可以使用媒体提取进行补充。使用文件系统映像,你可以从设备上获取所有信息,包括沙盒应用程序数据和具有多个记录的位置点,使用信息以及许多其他内容的系统数据库。

在取证当中,获取钥匙串是关键,钥匙串存储了用户的所有密码、加密密钥、证书、信用卡数据等。通过获取和解密钥匙串,你将能够解密来自那些号称最安全的聊天程序的聊天记录,访问设备所有者使用的其他云服务,以及执行更多操作。如果你不提取钥匙串,你就失去了可靠的证据。

要获得文件系统和密钥链,我们建议使用代理获取方法(如果兼容的话),因为这是最安全、最可靠的方法。但是,iOS版本和具有越狱功能的设备模型的支持范围略广。

最后,是对iCloud的取证。这种方法有很多优点,我们在以前已经介绍过多次。比如,无需手持设备,你就可以访问已从设备中删除的当前和以前的数据集。你可以从与同一账户相连的其他设备上获取一些其他数据,愿意的话,你还可以执行更多操作。

操作系统版本

对于逻辑获取,包括媒体文件和日志的提取,系统版本根本不重要。我们可以为所有的操作系统版本做到这一点,从古老的iOS 4到尚未发布的iOS 13.6测试版(撰写本文时的最新版本);结果大致相同。iOS 14的第一个测试版将于下周发布,几乎可以肯定,我们将能够从一开始就对其进行逻辑采集。

对于基于越狱的信息取证以及与我们的代理人进行的信息取证,我们不能采取相同的办法,这些方法取决于漏洞利用的可用性。它们确实存在于包括iOS 13.5(包括iOS 13.5)在内的大多数iOS版本中,但某些特定版本并未完全涵盖。例如,对于iPhone 5s和iPhone 6设备以及运行iOS 13.3.1至13.4.1的任何设备,我们只能提取文件系统,而不能提取iOS 12.3至12.4.7的钥匙串。最后,虽然iOS 13.5可以使用越狱功能,以获取文件系统和钥匙串,但你必须自己越狱,但你必须自己去越狱,代理不会帮忙的。对于iOS 13.5.1至13.6 beta 2,可以使用checkra1n(仅适用于兼容型号)。

对于tvOS,信息取证就困难重重了。存在类似的漏洞利用,但是越狱仅适用于tvOS 9- tvOS 12,范围非常有限的版本。只有tvOS 13可以对checkra1n越狱完全开放,理论上包括最新的13.4.8 beta,不过我们尚未对其进行测试。将来我们可能会为较旧的tvOS版本开发基于代理的获取,但目前尚无安全加密流量分析 (ETA) 。同时,Apple默认情况下会自动更新tvOS,因此用户的Apple TV将正常运行最新版本的tvOS。

至于watchOS,无论watchOS版本如何,都无需考虑文件系统的获取。watchOS很容易受到checkm8攻击,但是,没有适用于watchOS 5.2和更高版本的公开越狱(当前版本为watchOS 6.2.8 beta 2)。另一方面,Apple Watch收集的大多数信息都可以从与其配对的iPhone或从icloud中获得。但是,如果你具有IBUS适配器,则可以提取媒体文件和元数据(对于S1-S3系列手表)。

总结

正如我们之前所写的,在分析苹果设备时,并没有“一键解决方案”,尽管我们试图使工作流程尽可能简单。重要的是要了解硬件和软件的各种特性,并在选择提取方法时做出明智的信息取证方案。

由于新冠疫情的爆发,很多人不得不宅在家里,打游戏已经成为了人们消遣的主要方式了。随着游戏产业的崛起和人们对游戏的过多投入,黑客已经把攻击目标锁定在了游戏玩家身上。

与今年1月相比,4月份每天被阻止访问与游戏相关的恶意网站,或从与游戏相关的网站(论坛)浏览此类网站的次数增加了54%。5月份,该指标出现了下降趋势:与4月份相比下降了18%。

试图访问利用网络游戏主题的钓鱼网站被屏蔽的次数有所增加。特别值得一提的是,从2月到4月,来自Steam游戏平台虚假网站的通知数量增加了40%。

攻击者最常攻击的游戏是《我的世界》、《反恐精英:全球攻势》和《巫师3:狂猎》 (TheWitcher 3: Wild Hunt)。

受到此类攻击最多的用户来自越南(7.9%),阿尔及利亚(6.6%),韩国(6.2%),匈牙利(6.2%)和罗马尼亚(6%)。

来自各种来源的数据表明,由于冠状病毒大流行导致玩家活动急剧增加。根据gamesindustry.biz的数据,3月份,计算机和游戏机的游戏销量均大幅增长。

1.png

3月16日至22日当周的游戏销量增长

在4月份,Steam的下载数量以及在线播放器的数量都达到了创纪录的高峰。 下图的Steam用户活动图(包括游戏内和仅安装客户端)(数据来自Steam数据库)显示了4月4日那天用户的活动最多。此后,活动开始减少,速度也放缓了。此外,在疫情期间,玩家的游戏在线时间也比较长。

2.png

每天的Steam用户数

图中所反映的这些情况都是可以理解的,首先,人们有更多的空闲时间来玩游戏。 Nielsen Games收集的统计数据(作为对游戏玩家的定期调查的一部分)证实了这一论点:

3.png

不同国家/地区的玩家在玩视频游戏上花费的时间增加

其次,显然不是所有想花时间玩电子游戏的人都有一台能让他们玩游戏的电脑。通过查看Steam站点上显示的硬件统计数据,你可以了解到这一点。

如果你仔细查看包含Steam用户使用的显卡信息的图,可以看到图上的明显变化,该变化在2020年3月之前是完全平坦的。到目前为止,Nvidia,Intel和AMD的销售比例有了大幅增长。自隔离开始以来,英特尔和AMD显卡的份额已显着增长。在你还记得有超过2000万Steam用户之前,这一增长在2%以内,这似乎微不足道。也就是说,带有Intel和AMD显卡的设备数量增加了数十万台。考虑到不同制造商的显卡的特点,我们可以有把握地认为,这成百上千的设备是在隔离期间被送到家里的办公电脑,人们在老板无法看到的情况下安装了Steam。

4.png

这也被图表中Intel和AMD处理器比率的突然变化所证实(Intel也从隔离开始增长);玩家所使用的处理器在核数方面(4核和2核处理器所占比例的非典型增长):

5.1.png

5.2.png

当然,网络犯罪分子并没有注意到玩家数量的增加和他们在游戏中花费的时间。长期以来,游戏玩家一直是攻击者的最喜欢攻击目标,这些攻击者主要对游戏帐户的登录名和密码感兴趣。现在,随着家庭网络中的工作设备的增多,攻击者对玩家的攻击不仅可以直接获取攻击收益,也可以趁机摸清公司的基础架构。因为家庭网络相比公司网络来说,其安全防护程度要低得多,攻击者很容易监控玩家设备。

在2020年的前五个月中,Steam上发现的漏洞数量已经超过了前几年中发现的漏洞数量,这一事实表明攻击者对发现此类漏洞的兴趣日益浓厚。

6.png

也许你还记得,在2020年4月底,Valve曾经发现了流行网络游戏CS: GO和Team Fortress 2的源代码泄露,攻击者很可能已经在试图解析他们的代码,以寻找可以用于攻击目的的漏洞。重要的是要明白这些都不是离线游戏,而是需要连接到游戏服务器和频繁更新的在线游戏。这让他们的用户更容易受到攻击,因为他们的设备显然总是在线的,而玩家总是准备安装“更新”,以免失去玩游戏的最新能力。

但是,即使没有可用的零日漏洞,攻击者也有广阔的攻击空间,因为随着玩家数量的大幅增加,肯定会有大量的常见漏洞被安全小白所使用。

攻击者的逻辑是:随着玩家数量的增加,网络钓鱼攻击的概率也就越高。卡巴斯基反网络钓鱼和卡巴斯基安全网络(KSN)对此进行了确认。与2月份相比,在名称中包含“Steam”一词的数千个最受欢迎的钓鱼网站上的点击次数已大大增加,这种攻击在4月达到顶峰。

7.png

与2020年2月相比,网络钓鱼与Steam有关的主题的命中次数增加

使用游戏主题的网站的反病毒检测数据明显增加,例如,包含流行视频游戏和游戏平台的名称。

8.png

2020年1月至5月期间使用游戏主题进行网络攻击的次数

各种各样的恶意程序都带有很多恶意链接,比如窃取密码的恶意软件、勒索软件和挖矿软件。和往常一样,它们假冒流行游戏的免费版本、更新或扩展,以及欺骗程序。在使用与游戏相关的名称而不被注意的恶意文件中也可以观察到类似的情况。

使用与游戏相关的主题作为攻击渠道

9.png

这些统计数据并没有将黑客工具这类威胁考虑在内,这些工具通常是用户自己安装的,但可以用于恶意目的。我们在这个类别中包括远程访问客户端、流量分析器等。这个类别在这里很有趣,因为现代的欺骗程序经常使用与恶意软件相同的技术,如内存注入和利用漏洞绕过保护。如果我们将这种检测添加到统计数据中,它将以10%的份额占据首位。

根据从我们的网络防病毒获得的统计数据来看,攻击者最关注Minecraft的使用。 《巫师3:狂猎》也进入了被开发最多的游戏的前3名。

10.png

2020年1月至5月,以网络游戏为主题的攻击次数

根据对包含游戏名称的链接响应的动态变化的跟踪,我们得出的结论是,从4月到5月初,攻击者每次都在攻击时,一次性使用多个游戏作为攻击目标。尤其是《守望先锋》和《无名玩家》被使用的次数最多。如果你仔细看下面这张图,你会看到许多平行的峰值。

11.png

使用《守望先锋》和PUBG主题进行网络攻击

在越南攻击者可以非常容易地使用与游戏相关的主题进行攻击,在该国,几乎8%的网络防病毒检测都发生在使用游戏主题命名的网站上。

如下图所示,在2020年1月至5月,在以网络游戏为主题的攻击尝试中排名前20位的国家。

12.png

排在越南之后的前5个国家包括阿尔及利亚、韩国、匈牙利和罗马尼亚。总的来说,前20名包括北非、亚洲和欧洲,特别是南欧和东欧的许多国家。

总结

游戏产业在疫情期间迅速发展,当然,攻击者利用了这种趋势,我们发现尝试转向利用游戏主题的网络钓鱼站点的尝试显着增加。

但是,应该记住,这可不能全怪攻击者,而且还因为用户本身的粗心大意,他们显然是向游戏服务发送的虚假电子邮件,或者正在寻找被黑的用户,或寻求破解版本的一些流行的游戏和欺骗程序。不幸的是,在大多数情况下,网络罪犯不需要技术先进的方案即可发起成功的攻击。