煤矿中的金丝雀：使用DNS和AD检测枚举活动

 

引文

域名系统是任何网络中的基础组成部分。攻击者想要遍历活动目录（Active Directory）中计算机，并且建立连接，在某种程度上，它们可能会与DNS进行交互。一个简单的例子是尝试访问远程共享，就会导致下面的DNS查询。

因为DNS在内部网络的重要性，我们知道攻击者可能会使用它，这就给攻击按测提供了一个绝妙的检查点。我们控制着活动目录和DNS，所以我们可以控制敌人所能看到的东西。我们可以通过放置一小部分活动目录金丝雀和监视特定的DNS查询来实现这一点。

在早期的煤矿开采中，矿工们会在矿井里放一只金丝雀来探测有毒气体。在这篇文章中，我们将创建一些活动目录金丝雀来帮助我们检测遍历网络的威胁活动，我们会使用到HELK、SilkETW、DNS解析日志、Sysmon和一个假冒的SMB/SAMR服务器。

 

开始

记录详细DNS请求有点麻烦，根据组织的大小，我们可能需要一些额外的存储或性能考虑。我们目前可以选择记录DNS服务器级别或主机级别的DNS查询记录。这篇文章将讨论前者，而后续文章将讨论主机级别的监测、探测和欺骗。

为了在服务器上获得详细的DNS日志，我们需要启用Windows DNS解析日志（Windows DNS Analytical Logging）。相关内容在这里。

解析日志被认为是Windows日志的事件跟踪，并输出到“.etl”文件中。不幸的是，进行活动日志记录时，在事件查看器中并不能查看解析日志。但我们可以使用Microsoft Message Analyzer实时查看这些日志。通常，要将windows日志发送到SIEM，我们可以使用winlogbeat。但是在撰写本文时，winlogbeat不支持事件跟踪日志，因此我们需要其他的解决方案。一个非常强大的工具SilkETW可以满足我们的需求。

在本文的研究中，我使用HELK作为我的SIEM解决方案。按照wiki中的安装说明进行安装。完成HELK的安装后，我们需要对SilkETW传送的数据做一些准备。下图是我们的网络结构图。

在HELK实例中，我们需要确保端口9200处于监听状态并根据选择的安装进行映射。如果使用了DOCKER安装，我们可以使用sudo DOCKER ps查看端口9200是否映射到docker容器Elasticsearch的0.0.0.0地址。

如果这个端口没有处于监听状态，我们需要对它进行设置。在HELK/docker目录中，使用编辑器打开helk-kibana-analysis-basic.yml文件。添加如图所示的ports部分。

保存并关闭文件。重启Elasticsearch。在你的命令行窗口中执行下面的命令

export ADVERTISED_LISTENER=<your helk ip>
sudo -E docker-compose -f helk-kibana-analysis-basic.yml up --build –d

完成后，重新运行sudo docker ps来检查映射。

接下来，我们需要为来自SilkETW的数据创建一个索引。DNS解析日志的数据字段可以在这里找到)。

在Kibana控制台中，创建一个post请求。

现在，我们需要通过导航到管理页面来创建索引模式。

输入dnsqueries*来找到新的索引并选择下一步（Next step）按钮。

选择时间戳过滤器（Timestamp），点击创建索引模式（Create index pattern），完成创建。

现在，我们就可以使用SilkETW将日志数据转发到HELK实例。SilkETW需要日志的GUID，这样它就知道从哪里开始。我发现这个博客引用这个GUID {EB79061A-A566-4698-9119-3ED2807060E7}。

我们可以通过对网络上的另一个主机执行基本的nslookup来测试日志是否正确地发送到HELK。

现在，在Kibana的发现(discover)面板中，我们可以搜索DNS查询。

使用搜索过滤器XmlEventData.QNAME:"www.hackers.com"，我们可以快速找到特定的DNS查询。注意_source字段中的各种字段和数据。我们可以确定查询来自10.232.80.11。

到目前为止，我们已经设置了HELK、DNS解析日志记录、创建了索引和索引模式、启动了SilkETW并成功捕获了一个DNS查询。

 

金丝雀

我们从创建一个”金丝雀”计算机对象开始。在实际环境中，你需要尽可能详细地了解你的”金丝雀”。模拟其他对象的真实设置和在活动目录中的命名方案，以避免被攻击者识破这是一个陷阱。在本文的例子中，出于教学目的，我使用了明显的名称。

这个计算机对象将模拟我们的一个文件服务器。为了让DNS正常执行查找并看起来尽可能合法，我们需要为fakefileserver.spiderweb.local创建一个DNS条目。

创建好假文件服务器和DNS条目后，我们还可以创建一个”金丝雀”用户帐户。与其他对象一样，一定要设置一个诱人的描述、电话号码等，使帐户看起来尽可能合法。

重要的是，你需要将用户的“主文件夹”指向假的文件服务器。要使属性存在，而共享不必存在。

 

PowerView概述

PowerView是一个用于辅助活动目录枚举和利用的PowerShell脚本。它有许多内置函数，允许我们枚举用户、组、SPN、用户会话等等。并且可以从磁盘或内存中执行，还可以通过各种远程访问木马(RATs)执行。

PowerView中的许多方法都试图与远程主机交互。其中一个是Find-DomainUserLocation方法。此方法试图通过枚举会话来查找特定用户在网络中的位置。作为参考，可以了解MITRE ATT&CK框架T1049。首先，它查询所有计算机对象的活动目录。然后查询每台计算机的活动会话，并列出每个用户的会话来自何处。如果我们使用-stealth, PowerView将只枚举来自文件服务器的会话。这是在网络中查找用户位置的好方法。

这里的例子中显示“Al_Pacino”有一个从10.232.80.12到文件服务器的会话。

 

枚举检测

使用Find-DominUserLocation - Stealth来检查每个主机上的会话，它首先需要知道远程主机的位置。当连接到远程主机时，就会产生DNS查询。就其本身而言，对我们的HQFS01的DNS查询并没有异常，但是连接到我们的”金丝雀”假文件服务器的则是异常的。这样，我们可以在fakefileserver.spiderweb.local被解析时检测潜在的域枚举。之所以使用了Stealth选项，是因为PowerView将查看每个用户帐户并枚举主目录、脚本路径和配置文件路径。这些服务被认为是会产生大流量的服务，默认情况下将使用-Stealth进行扫描。我们的”金丝雀”用户有一个指向fakefileservershareusers的主目录，所以`Find-DomainUserLocation会试图从这里收集会话。

现在，让我们看看执行Find-DomainUserLocation - Stealth -Showall之后的HELK。

当Find-DomainUserLocation查询fakefileserver时，我们看到它有两个事件。我们可以通过添加更多的假文件服务器来提高检测的精确度。

 

使用Sysmon和假SMB/SAMR服务器增强检测

我们刚刚讨论了在服务器级别的日志上执行欺骗和检测。也就是说，我们所有的日志都是通过DNS解析日志（DNS Analytical Logging）在域控制器上执行的，并通过SilkETW转发给HELK。这种设置可以实现我们的目的，但是与使用基于主机的解决方案相比，我们丢失了数据的粒度。

首先需要在终端上设置Sysmon。在这里进行下载，参考这里来安装z-AlphaVersion.xml配置来启用DNS日志。

金丝雀设置

在这个场景中，我们的设置将包含一些额外的部分。

我们从创建一对”金丝雀”计算机对象开始。在实际环境中，你需要尽可能详细地了解你的”金丝雀”。模拟其他对象的真实设置和在活动目录中的命名方案，以避免被攻击者识破这是一个陷阱。在接下来的例子中，出于教学目的，我会使用非常明显的名称。

FAKEFILESERVER是一个运行我们修改过的响应会话枚举的程序smbserver的linux机器。

我们还需要创建另一个计算机对象，来运行我们修改过的smbserver，响应本地管理员组枚举的假SAMR服务器。我们称其为HQCITRIX01。

这个计算机对象将模拟我们的一个文件服务器。为了让DNS正常执行查找并看起来尽可能合法，我们需要为fakefileserver.spiderweb.local和HQCITRIX01.spiderweb.local创建DNS条目。

创建好假文件服务器和DNS条目后，我们还可以创建一个”金丝雀”用户帐户。与其他对象一样，一定要设置一个诱人的描述、电话号码等，使帐户看起来尽可能合法。

同样的将用户的“主文件夹”指向假文件服务器。

陷阱

我们的环境实现效果为：如果攻击者假冒终端并开始枚举网络上的会话和本地管理员，他们将看到我们选择的攻击路径。理想情况下，响应会话和SAMR查询的假SMB/SAMR服务器在查询时也会发送警报。

在我们的”金丝雀”主机上，我们使用标准的ubuntu服务器映像、impacket和修改后的smbserver.py。

impacke地址：https://github.com/SecureAuthCorp/impacket

CanaryServer地址：https://github.com/rvrsh3ll/CanaryServer

备份并且用我们修改的版本替换impacket/impacket/smbserver.py。

在impacket/目录下，执行pip install .。

impacket的smbserver.py的修改版本接受两个json文件作为数据，session_data.json 和samr_data.json。

我们将在fakefileserver上设置几个伪会话，并让它们指向不同的工作站。

用户will_smith是域管理员组的真实成员，并且有一个来自HQCITRIXSRV01的假会话。

接下来，我们在HQCITRIX01上设置假的SAMR数据。

将json文件保存到要运行smbserver.py的目录中。我把它们放在impacket/目录下。然后，只需启动smbserver.py。

我用“ ”作为共享名。当Get-NetShare运行时，它的效果是什么也不返回。

安全帐号管理器 (SAM) 远程协议为帐户存储或包含用户和组的目录提供管理功能。详情见https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-samr/96952411-1d17-4fe4-879c-d5b48a264314

我们的smbserver.py将响应本地管理员的SAMR枚举请求，在本例中，告诉枚举器“域用户”是HQCITRIX01上的本地管理员组的成员。

除了假数据之外，我们的环境还允许Sysmon将DNS查找转发到HELK实例。所有这些部分共同组成一个来检测攻击者枚举我们的网络资源的方案。

攻击

在这个场景中，攻击者在HQWKSTN01上登陆了一个钓鱼站点。他们想知道是否有攻击域管理员的路径。可以使用PowerView的Find-LocalAdminAccess和Get-NetSession等工具进行手动枚举，也可以使用BloodHound等工具以图形方式映射此路径。在我们的场景中，攻击者决定使用BloodHound，它将枚举活动目录中的用户，并通过查看用户属性(如主目录)来确定大流量服务器(如文件服务器)的位置。然后，它将尝试枚举这些服务器上的会话。BloodHound还将枚举活动目录中的计算机，并查询SAMR服务来枚举本地管理员。

当BloodHound正在查询会话和本地管理员数据时，我们可以看到查询击中了我们的假服务器。

下面是每个查询的攻击流。

检测

正如我们前面所讨论的，我们的”金丝雀”计算机的DNS查询会触发一些警报。现在，我们在每个主机上使用Sysmon和DNS日志，而不是SilkETW从DC转发DNS日志。这为我们提供了更多的细节，因为我们可以看到哪些进程正在进行查询。

这里我们看到字段dns_query_name匹配我们的”金丝雀”服务器主机名hqcitrix01.spiderweb.local。与DNS事务日志和SilkETW不同，我们可以看到关于查询的附加信息。最明显的是process_path字段。我们观察到关于我们的”金丝雀”的两个查询。

 

总结

这篇博文中涉及的欺骗和检测技术是与工具无关的。对”金丝雀”文件服务器的任何查询都应该进行调查。这篇博文介绍了在DNS服务器上使用DNS分析日志(DNS Analytical Logs)进行检测，并使用SilkETW将这些日志转发到SIEM。我还介绍了如何利用Sysmon(一个假冒的SMB/SAMR服务器)和HELK在主机级别进行”金丝雀”DNS的检测。