Active Directory is used in many networks and is often the target of attacks. In this article, I will demonstrate the capabilities of Suricata signatures to detect attacks against Active Directory.
Active Directory在许多网络中使用，并且经常成为攻击的目标。在本文中，我将演示Suricata签名检测针对Active Directory的攻击的功能。
Caster - If You Hadn't
Genre: Defensive
Label: exploit.org
Release Date: 27 May 2024
Performed by: Caster
Written by: Magama Bazarov
Cover Man: Magama Bazarov (Sony ILCE-7M3, f/5.6, 1/3 sec)
Intro
In this research, I will use Suricata to detect attacks against AD and demonstrate the signature writing process. That is, attack detection will take place at the network traffic level. By the way, it is an excellent option for those networks where it is not possible to buy an expensive IDS.
在本研究中，我将使用Suricata来检测针对AD的攻击，并演示签名的编写过程。也就是说，攻击检测将在网络流量级别进行。顺便说一句，对于那些不可能购买昂贵的IDS的网络来说，这是一个很好的选择。
This article will talk about detecting the following attacks:
本文将讨论如何检测以下攻击：
- LLMNR/NBT-NS Poisoning LLMNR/NBT-NS中毒
- IPv6 Takeover IPv6接管
- LDAP Enumeration & Bruteforce
LDAP枚举和暴力
- DCSync
- AS-REP Roasting AS-REP烘焙
- Kerberos User Enumeration & Bruteforce
用户枚举和暴力
LLMNR/NBT-NS Poisoning LLMNR/NBT-NS中毒
One of the most common attacks against Windows machines. The attacker responds to LLMNR/NBT-NS/MDNS requests from legitimate machines and then impersonates the requested hosts. Responder is typically used for this, it automates the process of this attack. As a result of the LLMNR/NBT-NS/MDNS poisoning, the attacker obtains the NetNTLMv2-SSP of the account from which the request was generated.
针对Windows机器的最常见攻击之一。攻击者响应来自合法计算机的LLMNR/NBT-NS/MDNS请求，然后冒充请求的主机。Responder通常用于此，它自动化此攻击的过程。LLMNR/NBT-NS/MDNS中毒的结果是，攻击者获得生成请求的帐户的NetNTLMv 2-SSP。
LLMNR Poisoning Detection
LLMNR中毒检测
In this case, you can write a signature to detect LLMNR Response packets that an attacker creates to trick Windows machines. An LLMNR Response packet in a Responder attack looks like this:
在这种情况下，您可以编写一个签名来检测攻击者为欺骗Windows计算机而创建的LLMNR响应数据包。响应者攻击中的LLMNR响应数据包如下所示：
LLMNR Response Packet LLMNR响应数据包
The byte sequence in this packet |80 00 00 01 00 01| indicates that this packet is an LLMNR Response. It is to this byte sequence that the following signature can be written:
该分组 |80 00 00 01 00 01| 中的字节序列指示该分组是LLMNR响应。以下签名可以写入该字节序列：
alert udp any 5355 -> any any (msg:"LLMNR Response Packet Detected, Possible LLMNR Poisoning"; flow:stateless; content:"|80 00 00 01 00 01|"; sid:1000000; rev:1;)
alert – indicates the type of rule. In this case, alert indicates that a warning will be generated when the rule is triggered;
alert -表示规则的类型。在这种情况下， alert 表示规则触发时会产生警告;
udp – indicates the transport layer protocol to which the rule will respond. udp indicates that the rule applies to UDP traffic;
udp -指示规则将响应的传输层协议。 udp 表示该规则适用于UDP流量;
any 5355 – Source IP and port parameters. This specifies that the source IP address can be anything and the source port is 5355, which is the standard port for LLMNR;
any 5355 -源IP和端口参数。这指定源IP地址可以是任何东西，源端口是 5355 ，这是LLMNR的标准端口;
-> – a direction symbol to indicate that traffic is going from source to destination;
-> -指示业务从源到目的地的方向符号;
any any – destination IP and port parameters. Indicates that the destination IP and port can be any;
any any -目的IP和端口参数。指示目的IP和端口可以是任意的;
msg: "LLMNR Response Packet Detected, Possible LLMNR Poisoning" is the message that will be displayed when the rule is triggered;
msg: "LLMNR Response Packet Detected, Possible LLMNR Poisoning" 是触发规则时显示的消息;
flow:stateless – specifies that traffic processing and inspection is independent of the state of the connection. A common practice for UDP traffic where there is no connection established before sending data, connectionless protocol;
flow:stateless -指定流量处理和检查独立于连接状态。UDP流量的常见做法，在发送数据之前没有建立连接，无连接协议;
content:"|80 00 00 00 01 00 00 01|" – the content being searched for in the packet, a byte sequence representing a specific part of the LLMNR packet, namely the response, which may be an indicator of an attack;
content:"|80 00 00 00 01 00 00 01|" -在分组中搜索的内容，表示LLMNR分组的特定部分的字节序列，即响应，其可以是攻击的指示符;
sid:1000000 -the unique rule identifier (SID, or Signature ID). This is a number that uniquely identifies a rule in a rule set;
sid:1000000 -唯一规则标识符（SID或签名ID）。这是唯一标识规则集中的规则的编号;
rev:1 – indicates the version of the rule. This is a number that is incremented when a rule is updated or modified.
rev:1 -表示规则的版本。这是一个在更新或修改规则时递增的数字。
Now to verify that this signature works:
现在验证此签名是否有效：
caster@kali:~$ sudo suricata -c /etc/suricata/suricata.yaml -r llmnrnbtnsmdnspoisoning.pcap
i: suricata: This is Suricata version 7.0.3 RELEASE running in USER mode
i: threads: Threads created -> RX: 1 W: 4 FM: 1 FR: 1 Engine started.
i: suricata: Signal Received. Stopping engine.
W: pcap: 1/5th of packets have an invalid checksum, consider setting pcap-file.checksum-checks variable to no or use '-k none' option on command line.
i: pcap: read 1 file, 185 packets, 25899 bytes
Suricata logs, detection of LLMNR Poisoning
Suricata日志，LLMNR中毒检测
Thus it is possible to detect poisoning attack on the LLMNR protocol using such a Suricata signature.
因此，可以使用这样的Suricata签名来检测对LLMNR协议的中毒攻击。
NBT-NS Poisoning Detection
NBT-NS中毒检测
Similar to the detection of LLMNR Poisoning, the same signature can be written for NBT-NS Poisoning. First we need to understand the structure of the packet that the attacker sends to attack:
类似于LLMNR中毒的检测，可以为NBT-NS中毒编写相同的签名。首先，我们需要了解攻击者发送攻击的数据包的结构：
NBT-NS Response Packet NBT-NS响应数据包
The byte sequence |85 00 00 00 00 01| indicates that this is specifically an NBT-NS Response packet. This byte sequence should be used to write a signature to detect suspicious NBT-NS Response packets.
字节序列 |85 00 00 00 00 01| 指示这具体是NBT-NS响应分组。此字节序列应用于写入签名以检测可疑的NBT-NS响应数据包。
The signature will look like the following:
签名将如下所示：
alert udp any 137 -> any 137 (msg:"NBT-NS Response Packet Detected, Possible NBT-NS Poisoning"; flow:stateless; content:"|85 00 00 00 00 01|"; sid:1000001; rev:1;)
alert – indicates the type of rule. In this case, alert indicates that a warning will be generated when the rule is triggered;
alert -表示规则的类型。在这种情况下， alert 表示规则触发时会产生警告;
udp – indicates the transport layer protocol to which the rule will respond. udp indicates that the rule applies to UDP traffic;
udp -指示规则将响应的传输层协议。 udp 表示该规则适用于UDP流量;
any 137 -> any 137 are the source and destination network addresses and ports. “any” indicates any IP address, and 5353 indicates the port that is used by the MDNS protocol;
any 137 -> any 137 是源和目的网络地址和端口。“any”表示任意IP地址，5353表示MDNS协议使用的端口;
msg: "NBT-NS Response Packet Detected, Possible NBT-NS Poisoning" is the message that will be displayed when the rule is triggered;
msg: "NBT-NS Response Packet Detected, Possible NBT-NS Poisoning" 是触发规则时显示的消息;
flow:stateless – specifies that traffic processing and inspection is independent of the state of the connection. A common practice for UDP traffic where there is no connection established before sending data, connectionless protocol;
flow:stateless -指定流量处理和检查独立于连接状态。UDP流量的常见做法，在发送数据之前没有建立连接，无连接协议;
content:"|85 00 00 00 00 00 00 00 01|" – the content that is being searched for in the packet, a byte sequence representing a specific part of the NBT-NS packet, namely the response, which can be an indicator of an attack;
content:"|85 00 00 00 00 00 00 00 01|" -在分组中正在搜索的内容，表示NBT-NS分组的特定部分的字节序列，即响应，其可以是攻击的指示符;
sid:1000001 – the unique rule identifier (SID, or Signature ID). This is a number that uniquely identifies a rule in a rule set;
sid:1000001 -唯一规则标识符（SID或签名ID）。这是唯一标识规则集中的规则的编号;
rev:1 – indicates the version of the rule. This is a number that is incremented when a rule is updated or modified.
rev:1 -表示规则的版本。这是一个在更新或修改规则时递增的数字。
Now to verify that this signature works:
现在验证此签名是否有效：
caster@kali:~$ sudo suricata -c /etc/suricata/suricata.yaml -r llmnrnbtnsmdnspoisoning.pcap
i: suricata: This is Suricata version 7.0.3 RELEASE running in USER mode
i: threads: Threads created -> RX: 1 W: 4 FM: 1 FR: 1 Engine started.
i: suricata: Signal Received. Stopping engine.
W: pcap: 1/5th of packets have an invalid checksum, consider setting pcap-file.checksum-checks variable to no or use '-k none' option on command line.
i: pcap: read 1 file, 185 packets, 25899 bytes
Suricata logs, detection of NBT-NS Poisoning
Suricata日志，NBT-NS中毒检测
NBT-NS Poisoning can be detected with such a signature.
NBT-NS中毒可以用这样的特征来检测。
MDNS Poisoning Detection MDNS中毒检测
MDNS is also a target for poisoning attack, essentially the same detection principle as in the case of LLMNR/NBT-NS. It is necessary to study the structure of the Response packet that the attacker sends:
MDNS也是中毒攻击的目标，基本上与LLMNR/NBT-NS的情况下相同的检测原理。有必要研究攻击者发送的响应包的结构：
MDNS Response Packet MDNS响应数据包
The byte sequence |84 00 00 00 00 01| will indicate that this is an MDNS Response packet. I will write a signature for this byte sequence:
字节序列 |84 00 00 00 00 01| 将指示这是MDNS响应数据包。我将为这个字节序列写一个签名：
alert udp any 5353 -> any 5353 (msg:"MDNS Response Packet Detected, Possible MDNS Poisoning"; flow:stateless; content:"|84 00 00 00 00 01|"; sid:1000002; rev:1;)
alert – indicates the type of rule. In this case, alert indicates that a warning will be generated when the rule is triggered;
alert -表示规则的类型。在这种情况下， alert 表示规则触发时会产生警告;
udp – indicates the transport layer protocol to which the rule will respond. udp indicates that the rule applies to UDP traffic;
udp -指示规则将响应的传输层协议。 udp 表示该规则适用于UDP流量;
any 5353 -> any 5353 are the source and destination network addresses and ports. “any” indicates any IP address, and 5353 indicates the port that is used by the MDNS protocol;
any 5353 -> any 5353 是源和目的网络地址和端口。“any”表示任意IP地址，5353表示MDNS协议使用的端口;
msg: "MDNS Response Packet Detected, Possible MDNS Poisoning" is the message that will be displayed when the rule is triggered;
msg: "MDNS Response Packet Detected, Possible MDNS Poisoning" 是触发规则时显示的消息;
flow:stateless – specifies that the processing and inspection of traffic is independent of the state of the connection. A common practice for UDP traffic where there is no connection established before sending data, connectionless protocol;
flow:stateless -指定流量的处理和检查与连接状态无关。UDP流量的常见做法，在发送数据之前没有建立连接，无连接协议;
content:"|84 00 00 00 00 00 00 00 00 01|" – content that is searched for in the packet, a byte sequence representing a specific part of the MDNS packet, namely the response, which can be an indicator of an attack;
content:"|84 00 00 00 00 00 00 00 00 01|" -在分组中搜索的内容，表示MDNS分组的特定部分的字节序列，即响应，其可以是攻击的指示符;
sid:1000002 – the unique rule identifier (SID, or Signature ID). This is a number that uniquely identifies a rule in a rule set;
sid:1000002 -唯一规则标识符（SID或签名ID）。这是唯一标识规则集中的规则的编号;
rev:1 – indicates the version of the rule. This is a number that is incremented when a rule is updated or modified.
rev:1 -表示规则的版本。这是一个在更新或修改规则时递增的数字。
Now to verify that this signature works:
现在验证此签名是否有效：
caster@kali:~$ sudo suricata -c /etc/suricata/suricata.yaml -r llmnrnbtnsmdnspoisoning.pcap
i: suricata: This is Suricata version 7.0.3 RELEASE running in USER mode
i: threads: Threads created -> RX: 1 W: 4 FM: 1 FR: 1 Engine started.
i: suricata: Signal Received. Stopping engine.
W: pcap: 1/5th of packets have an invalid checksum, consider setting pcap-file.checksum-checks variable to no or use '-k none' option on command line.
i: pcap: read 1 file, 185 packets, 25899 bytes
Suricata logs, detection of MDNS Poisoning
Suricata日志，MDNS中毒检测
These are the signatures that can be used to detect attacks on LLMNR/NBT-NS/MDNS protocols using Responder.
这些签名可用于使用Responder检测对LLMNR/NBT-NS/MDNS协议的攻击。
IPv6 Takeover IPv6接管
An attack in which an attacker imposes itself as a DNS server at the IPv6 level by sending specially generated DHCPv6 Advertise messages. The problem is that Windows prioritizes IPv6 over IPv4. Therefore, an attacker can intercept DNS queries. Typically, mitm6 is used for this attack.
一种攻击，攻击者通过发送专门生成的DHCPv 6认证消息，将自己强加为IPv6级别的DNS服务器。问题是Windows优先考虑IPv6而不是IPv4。因此，攻击者可以拦截DNS查询。通常，mitm 6用于此攻击。
RA Guard will not prevent this attack
RA警卫不会阻止这次袭击
It is through DHCPv6 messages that the attacker imposes itself as a DNS server, mitm6 can be run with the --no-ra flag, so RA Guard will not be an effective solution to combat mitm6.
正是通过DHCPv6消息，攻击者将自己强加为DNS服务器，mitm6可以使用 --no-ra 标志运行，因此RA Guard将不是对抗mitm6的有效解决方案。
DHCPv6 Packet Types DHCPv6数据包类型
The DHCPv6 protocol has the following message types:
DHCPv6协议具有以下消息类型：
- DHCPv6 Solicit: This message is initiated by the client to start communication with DHCPv6 servers. The client broadcasts or multicasts this message to discover available DHCP servers on the network. Upon receiving a Solicit message, DHCPv6 servers may respond with a DHCP Advertise message offering their configuration.
DHCPv6 Solicit：此消息由客户端发起，以开始与DHCPv6服务器通信。客户端广播或多播此消息以发现网络上可用的DHCP服务器。在接收到请求消息时，DHCPv6服务器可以用提供其配置的DHCP认证消息来响应。
- DHCPv6 Advertise: This message is sent by the DHCPv6 server in response to a DHCPv6 Solicit message from the client. It informs the client that the server is available to provide configuration settings, such as default gateway and DNS server.
DHCPv6请求：此消息由DHCPv6服务器发送，以响应来自客户端的DHCPv6 Solicit消息。它通知客户端服务器可用于提供配置设置，例如默认网关和DNS服务器。
- DHCPv6 Request: After receiving a DHCPv6 Advertise message, the client selects a DHCPv6 server and sends a DHCPv6 Request message to formally request the proposed settings. This message can also be used to confirm or update previously received configuration settings when the device reconnects to the network.
DHCPv6请求：在接收到DHCPv6认证消息后，客户端选择DHCPv6服务器并发送DHCPv6请求消息以正式请求建议的设置。当设备重新连接到网络时，此消息还可用于确认或更新先前收到的配置设置。
- DHCPv6 Reply: The DHCPv6 Reply message is used by the server to confirm the provisioning or updating of an IP address and other configuration parameters to a device. It can also be sent by the server in response to a DHCP Release message from a client when the client releases a leased IP address.
DHCPv6回复：服务器使用DHCPv6 Reply消息来确认向设备提供或更新IP地址和其他配置参数。当客户端释放租用的IP地址时，它也可以由服务器发送，以响应来自客户端的DHCP释放消息。
Attack Deconstruction 攻击解构
To write a signature, you need to clearly understand what static elements may be in the packet that could indicate suspicious activity. Let’s look at a DHCPv6 Advertise packet from the attacker’s machine.
要编写签名，您需要清楚地了解数据包中可能指示可疑活动的静态元素。让我们来看看来自攻击者机器的DHCPv6攻击数据包。
The |02| byte indicates that this is specifically a DHCPv6 Advertise packet. The presence of a DHCPv6 Advertise in the user segment is itself an anomaly, because this type of DHCPv6 message is sent only by a DHCPv6 server, which is not normally located on the user segment.
|02| 字节表示这是一个DHCPv6加密数据包。用户网段中存在DHCPv6验证本身就是一种异常，因为这种类型的DHCPv6消息仅由DHCPv6服务器发送，而该服务器通常不位于用户网段上。
Advertise package type information from RFC 8415
验证RFC 8415中的包类型信息
Based on this element in the DHCPv6 packet you can write a signature, it will look like this:
基于DHCPv 6数据包中的此元素，您可以编写签名，它看起来像这样：
alert udp any any -> any 546 (msg:"Suspicious DHCPv6 Advertise Packet Detected, Possible attack using mitm6"; content:"|02|"; depth:1; sid:1000008; rev:1;)
alert – indicates the type of rule. In this case, alert indicates that a warning will be generated when the rule is triggered;
alert -表示规则的类型。在这种情况下， alert 表示规则触发时会产生警告;
udp – indicates the transport layer protocol to which the rule will respond. udp indicates that the rule applies to UDP traffic;
udp -指示规则将响应的传输层协议。 udp 表示该规则适用于UDP流量;
any any -> any 546 – the first any indicates any source IP address, the second any indicates any source port, the arrow -> indicates the direction of traffic from source to destination, the third any indicates any destination IP address, 546 indicates the destination port, which is the standard port for DHCPv6 clients;
any any -> any 546 -第一个 any 指示任何源IP地址，第二个 any 指示任何源端口，箭头 -> 指示从源到目的地的流量方向，第三个 any 指示任何目的地IP地址， 546 指示目的地端口，这是DHCPv 6客户端的标准端口;
msg: "Suspicious DHCPv6 Advertise Packet Detected, Possible attack using mitm6" is the message that will be displayed when the rule is triggered;
msg: "Suspicious DHCPv6 Advertise Packet Detected, Possible attack using mitm6" 是触发规则时显示的消息;
content:"|02|" is an indication of the specific packet content that must be detected for the rule to be triggered. |02| means that the rule is looking for a packet that has the byte 02 in the specified position. An entry in the form |02| is used to denote a hexadecimal value in the content.
content:"|02|" 表示必须检测到的特定数据包内容，以便触发规则。 |02| 表示规则正在查找在指定位置具有字节 02 的数据包。格式为 |02| 的条目用于表示内容中的十六进制值。
depth:1 – specifies how deep in the packet to search for the specified content means that only the first byte of the packet should be checked;
depth:1 -指定在数据包中搜索指定的深度 content 意味着只应检查数据包的第一个字节;
sid:1000008 – the unique rule identifier (SID, or Signature ID). This is a number that uniquely identifies a rule in a rule set;
sid:1000008 -唯一规则标识符（SID或签名ID）。这是唯一标识规则集中的规则的编号;
rev:1 – indicates the version of the rule. This is a number that is incremented when the rule is updated or modified.
rev:1 -表示规则的版本。这是一个在更新或修改规则时递增的数字。
Verify that the signature works:
验证签名是否有效：
caster@kali:~$ sudo suricata -c /etc/suricata/suricata.yaml -r mitm6.pcap
i: suricata: This is Suricata version 7.0.3 RELEASE running in USER mode
i: threads: Threads created -> RX: 1 W: 4 FM: 1 FR: 1 Engine started.
i: suricata: Signal Received. Stopping engine.
i: pcap: read 1 file, 91 packets, 8006 bytes
Suricata logs, DHCPv6 Advertise packet detection
Suricata日志，DHCPv6验证数据包检测
In this way, it is possible to detect attacks using mitm6.
通过这种方式，可以使用mitm6检测攻击。
LDAP Attacks LDAP攻击
LDAP can also be a target for an attacker. It can be used in the initial collection of domain information, and there are also bruteforce attacks on accounts via LDAP.
LDAP也可能成为攻击者的目标。它可以用于域信息的初始收集，也有通过LDAP对帐户的暴力攻击。
Enumeration Detection 枚举检测
Like I said, LDAP can be used to gather domain information. In my lab network, I will be using the windapsearch tool. I will renumber the accounts, and then I need to examine the traffic recorded at the time of the attack.
正如我所说的，LDAP可以用来收集域信息。在我的实验室网络中，我将使用windapsearch工具。我会重新给账户编号，然后我需要检查攻击发生时的流量记录.
caster@kali:~/windapsearch$ python3 windapsearch.py --dc-ip 10.10.150.131 -u [email protected] -p Password123 --da
Traffic dump during LDAP enumeration
LDAP枚举期间的流量转储
An LDAP search request is a request to search for information in the LDAP directory. This query is used to retrieve entries from the directory that match certain criteria.
LDAP搜索请求是在LDAP目录中搜索信息的请求。此查询用于从目录中检索与特定条件匹配的条目。
LDAP Search requests have a Scope of Search:
LDAP搜索请求具有搜索范围：
- Base Object: Only the specified base object is searched.
基本对象：仅搜索指定的基本对象。
- Single Level: The search is performed one level below the specified base object.
单级：搜索在指定基础对象的下一级执行。
- Whole Subtree: The search covers the entire subtree starting from the specified base object and including all its subordinate objects.
整个子树：搜索覆盖从指定的基本对象开始的整个子树，包括其所有从属对象。
In my case windapsearch relies specifically on WholeSubtree to collect data:
在我的例子中，windapsearch特别依赖于 WholeSubtree 来收集数据：
WholeSubtree 整体子树
With WholeSubtree, an attacker can obtain information about all objects in a directory, including users, groups, security policies, and other resources. The byte sequence 0a 01 02 0a 01 00 indicates that this is a WholeSubtree.
使用 WholeSubtree ，攻击者可以获取目录中所有对象的信息，包括用户、组、安全策略和其他资源。字节序列 0a 01 02 0a 01 00 表示这是一个WholeSubtree。
The signature will look as follows:
签名如下所示：
alert tcp any any -> any 389 (msg:"An LDAP Search Request packet with WholeSubtree was detected, a possible Active Directory domain reconnaissance."; content:"|0a 01 02 0a 01 00|"; depth:38; sid:100005; rev:1;)
alert – signature keyword indicating that an alert should be generated if the specified conditions are met;
alert -签名关键字，指示在满足指定条件时应生成警报;
tcp – the protocol to be analyzed (TCP);
tcp -要分析的协议（TCP）;
any any – indicates that the traffic source can be any IP address and any port;
any any -表示流量来源可以是任意IP地址和任意端口;
-> – indicates the direction of traffic from source to destination;
-> -指示从源到目的地的流量方向;
any 389 – the destination IP address can be any IP address, but the destination; port must be 389 (the standard port for LDAP);
any 389 -目标IP地址可以是任何IP地址，但目标端口必须是389（LDAP的标准端口）;
msg:"An LDAP Search Request packet with WholeSubtree was detected, a possible Active Directory domain reconnaissance." – message that will be displayed when the rule is triggered;
msg:"An LDAP Search Request packet with WholeSubtree was detected, a possible Active Directory domain reconnaissance." -触发规则时显示的消息;
content:"|0a 01 02 0a 01 00|" – the content signature to search for in the packet;
content:"|0a 01 02 0a 01 00|" -要在数据包中搜索的内容签名;
depth:38 – indicates that this pattern should be found in the first 38 bytes of the packet. This helps to reduce false positives by checking only a certain part of the packet;
depth:38 -表示此模式应在数据包的前38个字节中找到。这有助于通过只检查数据包的某一部分来减少误报;
sid:1000005 – the unique rule identifier (SID, or Signature ID). This is a number that uniquely identifies a rule in a rule set;
sid:1000005 -唯一规则标识符（SID或签名ID）。这是唯一标识规则集中的规则的编号;
rev:1 – indicates the version of the rule. This is a number that is incremented when a rule is updated or modified.
rev:1 -表示规则的版本。这是一个在更新或修改规则时递增的数字。
Checking signature operation:
正在检查签名操作：
caster@kali:~$ sudo suricata -c /etc/suricata/suricata.yaml -r windapsearch-da.pcap
i: suricata: This is Suricata version 7.0.3 RELEASE running in USER mode
i: threads: Threads created -> RX: 1 W: 4 FM: 1 FR: 1 Engine started.
i: suricata: Signal Received. Stopping engine.
i: pcap: read 1 file, 1793 packets, 822860 bytes
Suricata logs, detection of LDAP Enumeration (WholeSubtree)
Suricata日志，LDAP枚举检测（WholeSubtree）
Bruteforce Detection 暴力检测
Bruteforce attack is also possible against the LDAP protocol. In this case, you can get by with a rule that will detect 70 packets in 1 minute, which would indicate LDAP bruteforcing or port scanning against LDAP.
暴力攻击也可能针对LDAP协议。在这种情况下，您可以使用一个在1分钟内检测70个数据包的规则，这将指示LDAP暴力或针对LDAP的端口扫描。
alert tcp any any -> any 389 (msg:"Potential LDAP bruteforce attack"; flow:to_server; threshold: type threshold, track by_src, count 70, seconds 60; sid:1000006; rev:1;)
alert tcp any any -> any 389 – this part specifies that the rule applies to TCP traffic from any source IP address and any source port to any destination IP address and destination port 389;
alert tcp any any -> any 389 -此部分指定规则适用于从任何源IP地址和任何源端口到任何目的IP地址和目的端口的TCP流量389;
msg:"Potential LDAP bruteforce attack – message that will be displayed when the rule is triggered;
msg:"Potential LDAP bruteforce attack -触发规则时显示的消息;
flow:to_server – this specifies the direction of the traffic. In this case, it indicates that the rule should inspect traffic flowing to the server;
flow:to_server -指定流量的方向。在这种情况下，它表示规则应该检查流向服务器的流量;
threshold: type threshold, track by_src, count 70, seconds 60 – this sets the conditions for triggering the rule. It specifies a threshold where the rule will trigger if there are 70 or more connections (count 70) from the same source IP address (track by_src) to the destination within a 60-second period (seconds 60). This is indicative of a potential brute force attack, where multiple authentication attempts are made in a short time frame;
threshold: type threshold, track by_src, count 70, seconds 60 -设置触发规则的条件。它指定了一个阈值，如果在60秒内（ seconds 60 ）有70个或更多从同一源IP地址（ track by_src ）到目的地的连接（ count 70 ），则将触发该规则。这表明存在潜在的暴力攻击，即在短时间内进行多次身份验证尝试;
sid:1000006 – this is the Signature ID (SID) for the rule, a unique identifier for the rule;
sid:1000006 -这是规则的签名ID（SID），规则的唯一标识符;
rev:1 – this indicates the revision number of the rule, which is used for version control.
rev:1 -表示规则的修订号，用于版本控制。
caster@kali:~$ sudo suricata -c /etc/suricata/suricata.yaml -r ldapbruteforce.pcap
i: suricata: This is Suricata version 7.0.3 RELEASE running in USER mode
i: threads: Threads created -> RX: 1 W: 4 FM: 1 FR: 1 Engine started.
i: suricata: Signal Received. Stopping engine.
i: pcap: read 1 file, 1785 packets, 191901 bytes
Suricata logs, detection of LDAP Bruteforce
Suricata日志，LDAP Bruteforce检测
For LDAPS: 对于LDAPS：
alert tcp any any -> any 636 (msg:"Potential LDAPS bruteforce attack"; flow:to_server; threshold: type threshold, track by_src, count 70, seconds 60; sid:1000007; rev:1;)
LDAP attacks can be detected with these signatures.
LDAP攻击可以通过这些特征码检测到。
DCSync
One of the post-exploitation techniques. The DCSync attack is one of the attack techniques against Active Directory (AD) infrastructure used to extract user password hashes from a domain. This attack exploits standard data replication mechanisms between domain controllers in AD. This DCSync attack allows an attacker to emulate the behavior of a domain controller and request AD to replicate data.
一种后期开发技术。DCSync攻击是针对Active Directory（AD）基础结构的攻击技术之一，用于从域中提取用户密码哈希。此攻击利用AD中域控制器之间的标准数据复制机制。此DCSync攻击允许攻击者模拟域控制器的行为并请求AD复制数据。
This attack is performed using Mimikatz or Impacket (secretsdump)
此攻击使用Mimikatz或Impacket（secretsdump）执行
Traffic analysis 流量分析
You need to analysis the traffic to figure out exactly what to write a signature for.
您需要分析通信量，以确定要为哪些内容编写签名。
DCERPC Traffic DCERPC流量
There’s an interesting picture emerging here. First of all, it involves a Bind request to use the DRSUAPI interface. Secondly, DRSUAPI in turn is the interface for managing data replication in Active Directory.
这里出现了一幅有趣的画面。首先，它涉及使用DRSUAPI接口的Bind请求。其次，DRSUAPI又是管理Active Directory中数据复制的接口。
Then we come to the second interesting packet – DsGetNCChanges request DsGetNCChanges is the primary mechanism for requesting data replication in Active Directory. In a DCSync attack, an attacker uses this request to retrieve sensitive data such as user password hashes.
然后我们来到第二个有趣的数据包- DsGetNCChanges request DsGetNCChanges是在Active Directory中请求数据复制的主要机制。在DCSync攻击中，攻击者使用此请求检索敏感数据，如用户密码哈希。
Signature Writing 签名书写
I think it is these suspicious packets that you can write signatures for. However, a single rule will not be enough as we need to capture two packets. Therefore, we will have to bind them by flowbit
我认为你可以为这些可疑的包裹签名。然而，一个规则是不够的，因为我们需要捕获两个数据包。因此，我们必须通过 flowbit 绑定它们
First, a special rule is needed to detect the Bind request and use the DRSUAPI interface.
首先，需要一个特殊的规则来检测Bind请求并使用DRSUAPI接口。
Byte sequences for Bind requests and DRSUAPI UUID
Bind请求和DRSUAPI UUID的字节序列
The byte sequence |05 00 0b| indicates the DCERPC protocol version, minor version and also indicates that this is a Bind request.
字节序列 |05 00 0b| 指示DCERPC协议版本、次要版本，并且还指示这是绑定请求。
|05| – version; |05| -版本;
|00| – version (minor); |00| – version（minor）;
|0b| – Bind request; |0b| -绑定请求;
Then the byte sequence 35 42 51 e3 06 4b d1 11 ab 04 00 c0 4f c2 dc d2 points to the UUID of the DRSUAPI interface. The presence of this sequence in the packet indicates the use of DRSUAPI, which is natural to a DCSync attack:
然后字节序列 35 42 51 e3 06 4b d1 11 ab 04 00 c0 4f c2 dc d2 指向DRSUAPI接口的UUID。数据包中存在此序列表示使用了DRSUAPI，这对于DCSync攻击来说是很自然的：
DRSUAPI interface UUID in bytes
DRSUAPI接口UUID（字节）
The first rule for DCSync discovery would look like this:
DCSync发现的第一条规则如下所示：
alert tcp any any -> any any (msg:"DRSUAPI interface usage detected"; flowbits:set,drsuapi; flowbits:noalert; content:"|05 00 0b|"; depth:3; content:"|35 42 51 e3 06 4b d1 11 ab 04 00 c0 4f c2 dc d2|"; depth:100; sid:1000003; rev:1;)
alert – indicates the type of rule. In this case it is “alert”, which means that it creates an alert when the corresponding packet is detected;
alert -表示规则的类型。在这种情况下，它是“alert”，这意味着它在检测到相应的数据包时创建警报;
tcp – the protocol to which the rule applies. In this case it is TCP;
tcp -规则适用的协议。在这种情况下，它是TCP;
any any -> any any – specifies the source and destination addresses and ports. “any any” means that the rule applies to all IP addresses and ports of both source and destination.
any any -> any any -指定源和目的地址以及端口。“any any”表示该规则适用于源和目的地的所有IP地址和端口。
msg: "DRSUAPI interface usage detected" – the message that will be output when the rule is triggered;
msg: "DRSUAPI interface usage detected" -规则触发时输出的消息;
flowbits:set,drsuapi – use flowbits to set a bit named “drsuapi”;
flowbits:set,drsuapi -使用flowbits设置一个名为“drsuapi”的位;
flowbits:noalert – specifies that this rule should not generate alerts on its own, even if its conditions are met. This is necessary in this case because we need a second rule for accurate detection;
flowbits:noalert -指定此规则不应自行生成警报，即使满足其条件也是如此。在这种情况下，这是必要的，因为我们需要第二个规则来进行精确检测;
content:"|05 00 0b|" – the content signature to search for in the packet;
content:"|05 00 0b|" -要在数据包中搜索的内容签名;
depth:3 – specifies that the above content check should be performed in the first 3 bytes of the packet payload;
depth:3 -指定应在数据包有效载荷的前3个字节中执行上述内容检查;
content:"|35 42 51 e3 06 4b d1 11 ab 04 00 c0 4f c2 dc d2|" – another content signature to look for in the packet;
content:"|35 42 51 e3 06 4b d1 11 ab 04 00 c0 4f c2 dc d2|" -要在数据包中查找的另一个内容签名;
depth:100 – indicates that the above content check should be performed in the first 100 bytes of the packet payload;
depth:100 -表示上述内容检查应在分组净荷的前100个字节中执行;
sid:1000003 – the unique rule identifier (SID, or Signature ID). This is a number that uniquely identifies a rule in a rule set;
sid:1000003 -唯一规则标识符（SID或签名ID）。这是唯一标识规则集中的规则的编号;
rev:1 – indicates the version of the rule. This is a number that is incremented when a rule is updated or modified.
rev:1 -表示规则的版本。这是一个在更新或修改规则时递增的数字。
Now a second rule is needed.
现在需要第二条规则。
DsGetNCChanges request packet
DsGetNCChanges请求数据包
The byte sequence |05 00 00| indicates that this is specifically an RPC request
字节序列 |05 00 00| 表示这是一个RPC请求
|05| – version; |05| -版本;
|00| – minor version; |00| -次要版本;
|00| – RPC request. |00| – RPC请求。
Then another byte sequence: |03 00| – opnum 3 indicates that this is specifically a DsGetNCChanges function. The signature for detecting DsGetNCChanges would be as follows:
然后另一个字节序列： |03 00| – opnum 3 表示这是一个具体的 DsGetNCChanges 函数。用于检测 DsGetNCChanges 的签名将如下：
alert tcp any any -> any any (msg:"DsGetNCChanges request packet was detected. Possible DCSync attack"; flowbits:isset,drsuapi; content:"|05 00 00|"; depth:3; content:"|03 00|"; offset:22; depth:2; sid:1000004; rev:1;)
alert tcp any any -> any any – specifies that this rule applies to any TCP packets that can be sent from any port to any port;
alert tcp any any -> any any -指定此规则适用于可以从任何端口发送到任何端口的任何TCP数据包;
msg:"DsGetNCChanges request packet was detected. Possible DCSync attack" – indicates that the corresponding message will be displayed when the rule is triggered;
msg:"DsGetNCChanges request packet was detected. Possible DCSync attack" -表示触发规则时会显示相应的消息;
flowbits:isset,drsuapi – the rule checks if the flowbits variable named drsuapi is set. Flowbits is used to track status and exchange information between rules. If the drsuapi variable was set by another rule earlier, then the first rule to detect the use of the DRSUAPI interface;
flowbits:isset,drsuapi -规则检查是否设置了名为 drsuapi 的flowbits变量。Flowbits用于跟踪状态并在规则之间交换信息。如果drsuapi变量之前是由另一个规则设置的，那么第一个规则检测DRSUAPI接口的使用;
content:"|05 00 00|" – indicates that the rule is looking for the byte sequence 05 00 00 in the packet;
content:"|05 00 00|" -表示规则正在数据包中查找字节序列 05 00 00 ;
depth:3 – the search depth is limited to the first three bytes of the packet. This means that content:"|05 00 00|" must be found in the first three bytes of the packet;
depth:3 -搜索深度限于数据包的前三个字节。这意味着必须在数据包的前三个字节中找到 content:"|05 00 00|" ;
content:"|03 00|" – indicates that the rule is looking for the byte sequence 03 00 in the packet;
content:"|03 00|" -表示规则正在数据包中查找字节序列 03 00 ;
offset:22 – indicates that the search for the 03 00 sequence starts at the 22nd byte of the packet. A more precise search for this sequence reduces the number of false positives. Without offset:22, the rule would be less specific and could trigger on other packets containing 03 00 anywhere. Using an offset makes the rule more precise and specific to the target traffic;
offset:22 -表示从数据包的第22个字节开始搜索 03 00 序列。对该序列的更精确的搜索减少了假阳性的数量。如果没有 offset:22 ，规则将不太具体，并且可以在任何地方触发包含 03 00 的其他数据包。使用偏移量使规则更精确，更具体地针对目标流量;
depth:2 – the search depth of the second byte sequence is limited to two bytes starting at the 22nd byte of the packet;
depth:2 -第二字节序列的搜索深度限于从分组的第22字节开始的两个字节;
sid:1000004 – the unique rule identifier (SID, or Signature ID). This is a number that uniquely identifies a rule in a rule set;
sid:1000004 -唯一规则标识符（SID或签名ID）。这是唯一标识规则集中的规则的编号;
rev:1 – indicates the version of the rule. This is a number that is incremented when a rule is updated or modified.
rev:1 -表示规则的版本。这是一个在更新或修改规则时递增的数字。
Now to verify that the signature works:
现在验证签名是否有效：
caster@kali:~$ sudo suricata -c /etc/suricata/suricata.yaml -r dcsync.pcap
i: suricata: This is Suricata version 7.0.3 RELEASE running in USER mode
i: threads: Threads created -> RX: 1 W: 4 FM: 1 FR: 1 Engine started.
i: suricata: Signal Received. Stopping engine.
W: pcap: 1/1th of packets have an invalid checksum, consider setting pcap-file.checksum-checks variable to no or use '-k none' option on command line.
i: pcap: read 1 file, 96 packets, 33650 bytes
Suricata logs, detection of DCSync Attack
Suricata日志，DCSync攻击检测
This is how you can detect a DCSync attack by tracking the use of the DRSUAPI interface and the DsGetNCChanges packet.
这就是通过跟踪DRSUAPI接口和 DsGetNCChanges 数据包的使用来检测DCSync攻击的方法。
AS-REP Roasting AS-REP烘焙
AS-REP Roasting – is a Kerberos protocol attack method that targets Active Directory accounts that have pre-authentication disabled.
AS-REP Roasting -是一种IPSec协议攻击方法，目标是已禁用预身份验证的Active Directory帐户。
How this attack works 这种攻击是如何运作的
I’ll explain this attack briefly. It is conducted in several stages:
我来简单解释一下这次袭击。它分几个阶段进行：
- AS-REP Request: The attack begins by sending an authentication request (AS-REQ) on behalf of an account that does not require a Pre-Authentication mechanism. Such accounts are specifically configured without requiring Pre-Authentication to simplify the attack process;
AS-REP请求：攻击首先代表不需要预身份验证机制的帐户发送身份验证请求（AS-REQ）。此类账户经过专门配置，无需预认证，简化攻击过程;
- AS-REP Response: The domain controller responds (AS-REP) and includes an encrypted TGT (Ticket Granting Ticket) that is encrypted using the account password hash;
AS-REP回复：域控制器响应（AS-REP）并包括使用帐户密码散列加密的加密TGT（票证授予票证）;
- Hash Extraction: An attacker intercepts this AS-REP response and extracts encrypted data from it, which can be thought of as a hash of the account password;
哈希提取：攻击者拦截此AS-REP响应并从中提取加密数据，这些数据可以被认为是帐户密码的散列;
- Hash analysis: The obtained hash can be brute-force or rainbow tables attacked to obtain the account password.
哈希分析：获取的哈希可以被暴力破解或彩虹表攻击，从而获取账户密码。
AS-REP Roasting (impacket-GetNPUsers)
AS-REP Roasting（impacket-GetNPUsers）
First, I will run an AS-REP Roasting attack using impacket-GetNPUsers to analyze the traffic:
首先，我将使用 impacket-GetNPUsers 运行AS-REP Roasting攻击来分析流量：
caster@kali:~/kerberos-research$ impacket-GetNPUsers -dc-ip 192.168.0.71 myownsummer.org/ -usersfile usernames.txt -format hashcat -outputfile hashes.txt
Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation
[email protected]:c494472eb2709a075425bdea0b4518a6$57a21fd2f10f707590048d8bcc23463abffef99ed0705b62bb8c04dabf156ef55153d04d83b960ad106777afda3dc21589b55616f1849c5e691e5a947668ffaf1ad27a35d7d1d4ee6e8b37fc7a764a86f9d5e761d2a0952260683fa847fdfa175dd3940321d14961ca428883be81837c89d358c0344c58d83eac327b5667efcb0443ad5d2c20a398d318897fc9a6522b6d3a57410989e07db5ba1b1a5be52d5e70e84ff0372b39291fc01a7d5b8e7a3fb3a7f34d56c13a5b0b3c2c2605bfcf3741696d7f3239ec20fd4643967f010f6c293ffdb974d3bb7867c6b0cc0541c21c8981f0aac073947e659b8a968612a51fee52
[email protected]:551a7700665fdc828ec80d10f566cf4c$e4ab451eae086256c57c91ebb993bb9c3b255d8ff716bdcdcc589a932c3494e35a8649fe7c6b6049abbddbf2c409ed48d9807f9bf2b70cc46486149637ad577c26df4ee6cc1015a08365812d8355cca593b256adf47eb227f8a1e083b93652635f961617f5d4144c0e25f70e27f5e8f782ebc08bc0934776d1edb30c120405d3ae04a474b7611574b8f724a9c45ae057448dacf4a0f6f7b38fa8ad879158ce12dba086190d6e3cf93ba214d5a8c182217b874aefaa284331f5dbd16a059768643079b1a6fa6a26e39e5f3c4a981cf630819dd04c3b18f6e399a93a22fc19a66b8e66553bdff2c6cfe669a29d35e83cf3dbc9
In my case, only two users of the myownsummer.org domain have pre-authentication disabled, which is the point of AS-REP Roasting.
在我的例子中， myownsummer.org 域只有两个用户禁用了预身份验证，这就是AS-REP Roasting的意义。
Analysis of the AS-REQ packet. This byte sequence a0 07 03 05 00 50 80 00 00 a1 indicates the body of the AS-REQ request:
分析AS-REQ数据包。该字节序列 a0 07 03 05 00 50 80 00 00 a1 指示AS-REQ请求的主体：
KRB AS-REQ Body KRB AS-EQUIPMENT阀体
Also worth noting is krbtgt, this string is a key indicator because krbtgt is the account name of the Kerberos Ticket Granting Ticket (TGT) service. In AS-REP Roasting attacks, the attacker attempts to obtain encrypted data for this account to then attempt to crack passwords. The string krbtgt is pointed to by the byte sequence 6b 72 62 74 67 74
另外值得注意的是 krbtgt ，这个字符串是一个关键的指示符，因为 krbtgt 是TGT服务的帐户名称。在AS-REP Roasting攻击中，攻击者尝试获取此帐户的加密数据，然后尝试破解密码。字符串 krbtgt 由字节序列 6b 72 62 74 67 74 指向
krbtgt string krbtgt串
I wrote the following signature to detect AS-REP Roasting:
我写了以下签名来检测AS-REP Roasting：
alert tcp any any -> any 88 (msg:"Suspicious Kerberos Packet, Possible AS-REP Roasting attack"; flow: to_server, stateless; content:"|a0 07 03 05 00 50 80 00 00 a1|"; content:"|6b 72 62 74 67 74|"; fast_pattern; content:!"|a2 03 02 01 0c|"; sid:1000008; rev:1;)
alert – indicates that an alert will be generated when the rule is triggered;
alert -表示触发规则时会产生预警;
tcp – indicates that the rule applies to TCP traffic;
tcp -表示该规则适用于TCP流量;
any any -> any 88 – the rule will apply to any source IP address and port and any target IP address on port 88, which is the default port for Kerberos;
any any -> any 88 -该规则将应用于任何源IP地址和端口以及端口88上的任何目标IP地址，端口88是TCP的默认端口;
msg:"Suspicious Kerberos Packet, Possible AS-REP Roasting attack" – message that will be output when the signature is triggered. In this case, the message indicates a possible AS-REP Roasting attack;
msg:"Suspicious Kerberos Packet, Possible AS-REP Roasting attack" -触发签名时输出的消息。在这种情况下，该消息指示可能的AS-REP Roasting攻击;
flow: to_server, stateless;:
flow: to_server – specifies that the signature should only trigger on traffic directed to the server;
flow: to_server -指定签名应该仅在定向到服务器的流量上触发;stateless – indicates that the signature operates without regard to the state of the connection;
stateless -表示签名的操作与连接状态无关;
content:"|a0 07 03 05 00 50 80 00 00 a1|" – sequence of bytes indicating the body of the AS-REQ request;
content:"|a0 07 03 05 00 50 80 00 00 a1|" -指示AS-REQ请求的主体的字节序列;
content:"|6b 72 62 74 67 74|"; fast_pattern;:
content:"|6b 72 62 74 67 74|" – points to the string krbtgt
content:"|6b 72 62 74 67 74|" -指向字符串 krbtgtfast_pattern – indicates that this string is used for quick matching at the beginning of the packet content check;
fast_pattern -表示此字符串用于在包内容检查开始时进行快速匹配;
content:!"|a2 03 02 01 0c|";:
! – means a negative condition, i.e. the rule should work if the specified sequence is not present in the packet;
! -表示否定条件，即如果指定的序列不存在于数据包中，则规则应该起作用;a2 03 02 01 0c – is a sequence of bytes indicating the presence of pre-authentication. The absence of this sequence indicate the possibility of an AS-REP Roasting attack.
a2 03 02 01 0c -是指示存在预认证的字节序列。缺少此序列表明可能存在AS-REP Roasting攻击。
sid:100001 – unique signature identifier;
sid:100001 -唯一签名标识符;
rev:1 – signature version indicating its revision
rev:1 -签名版本，表明其修订版
Verify that this signature works:
验证此签名是否有效：
caster@kali:~/kerberos-research$ sudo suricata -c /etc/suricata/suricata.yaml -r asreproasting-impacket.pcap
i: suricata: This is Suricata version 7.0.3 RELEASE running in USER mode
i: threads: Threads created -> RX: 1 W: 4 FM: 1 FR: 1 Engine started.
i: suricata: Signal Received. Stopping engine.
W: pcap: 1/1th of packets have an invalid checksum, consider setting pcap-file.checksum-checks variable to no or use '-k none' option on command line.
i: pcap: read 1 file, 198 packets, 22824 bytes
This is the signature that can be used to detect AS-REP Roasting using impacket-GetNPUsers.
这是可用于使用impacket-GetNPUsers检测AS-REP Roasting的签名。
Why does the absence of bytes a2 03 02 01 01 01 01 0c indicate no pre-authentication?
为什么没有字节a2 03 02 01 01 01 01 0 c表示没有预认证？
Kerberos uses pre-authentication to prevent certain types of attacks. When pre-authentication is enabled, the client must include a timestamp encrypted with the user’s key in its AS-REQ request. This timestamp is then verified by the domain controller to confirm the authenticity of the request.
防毒墙网络版使用预身份验证来防止某些类型的攻击。当启用预身份验证时，客户端必须在其AS-REQ请求中包含一个使用用户密钥加密的时间戳。然后域控制器验证此时间戳以确认请求的真实性。
Kerberos uses ASN.1 (Abstract Syntax Notation One) to encode its messages. In the case of pre-authentication, a certain structure is included in the AS-REQ request, which may look like the following:
以太网使用ASN.1（抽象以太网表示法一）对其消息进行编码。在预身份验证的情况下，AS-REQ请求中包含特定结构，可能如下所示：
a2 – Context-specific tag.
a2 -特定于上下文的标签。
03 – Length of the following byte sequence (3 bytes).
03 -后续字节序列的长度（3个字节）。
02 01 0c – INTEGER value 12 (0x0c) indicating the use of pre-authentication.
02 01 0c -整数值12（0x 0 c），表示使用预身份验证。
a2 03 02 01 0c
If pre-authentication is disabled, this structure will be missing from the AS-REQ request. Therefore, searching for the absence of this byte sequence allows you to identify accounts that have pre-authentication disabled, making them vulnerable to AS-REP Roasting attacks.
如果禁用预身份验证，AS-REQ请求中将缺少此结构。因此，通过搜索不存在此字节序列，您可以识别已禁用预身份验证的帐户，从而使它们容易受到AS-REP Roasting攻击。
Thus, the content:!"|a2 03 02 01 0c|" element in the signature indicates the lack of pre-authentication in the AS-REQ request, which is an indicator of vulnerability to AS-REP Roasting attacks.
因此，签名中的 content:!"|a2 03 02 01 0c|" 元素指示AS-REP请求中缺少预认证，这是对AS-REP Roasting攻击的脆弱性的指示符。
AS-REP Roasting Attack (Rubeus)
AS-REP Roasting Attack（Rubeus）
During AS-REP Roasting attack using Rubeus I noticed that the byte sequence for AS-REQ body is slightly different from the byte sequence for AS-REQ body when I run impacket-GetNPUsers I think it has to do with the peculiarities of the implementation of these tools.
在使用Rubeus进行AS-REP Roasting攻击时，我注意到AS-REP体的字节序列与运行 impacket-GetNPUsers 时AS-REP体的字节序列略有不同，我认为这与这些工具的实现特性有关。
Rubeus 鲁伯
KRB AS-REQ byte sequence (Rubeus)
KRB AS-10字节序列（Rubeus）
KRB AS-REQ byte sequence (impacket-GetNPUsers)
KRB AS-字节序列（impacket-GetNPUsers）
In fact, the signature for AS-REP Roasting when using Rubeus is not much different from the signature for AS-REP Roasting when using impacket-GetNPUsers:
实际上，使用Rubeus时AS-REP Roasting的签名与使用impacket-GetNPUsers时AS-REP Roasting的签名没有太大区别：
alert tcp any any -> any 88 (msg:"Suspicious Kerberos Packet, Possible AS-REP Roasting attack (Rubeus)"; flow: to_server, stateless; content:"|a0 07 03 05 00 40 80 00 10 a1|"; content:"|6b 72 62 74 67 74|"; fast_pattern; content:!"|a2 03 02 01 0c|"; sid:100002; rev:1;)
Checking this signature:
检查此签名：
caster@kali:~/kerberos-research$ sudo suricata -c /etc/suricata/suricata.yaml -r asreproast-rubeus.pcap
i: suricata: This is Suricata version 7.0.3 RELEASE running in USER mode
i: threads: Threads created -> RX: 1 W: 4 FM: 1 FR: 1 Engine started.
i: suricata: Signal Received. Stopping engine.
W: pcap: 1/7th of packets have an invalid checksum, consider setting pcap-file.checksum-checks variable to no or use '-k none' option on command line.
i: pcap: read 1 file, 286 packets, 339846 bytes
Detected AS-REP Roasting (Rubeus)
检测到AS-REP烘烤（Rubeus）
Kerberos User Enumeration & Bruteforce
用户枚举和暴力
On the network, an attacker can perform user enumeration using kerbrute, also use it to perform Password Spray attacks, password brute force, etc.
在网络上，攻击者可以使用kerbrute执行用户枚举，也可以使用它来执行密码喷射攻击，密码暴力破解等。
But the problem for the attacker is that kerbrute requires AS-REQ packets to be sent, and this happens at a very fast speed. This can be a jumping off point for signature writing, because for example 10 AS-REQs sent in 30 seconds is an anomalous behavior that network engineers will pay attention to.
但攻击者面临的问题是，kerbrute需要发送AS-RTP包，而且速度非常快。这可能是签名写入的起点，因为例如在30秒内发送10个AS-REQ是网络工程师将注意的异常行为。
Here is an example of a kerbrute exploit in which the attacker searched for existing users in an Active Directory domain.
下面是一个利用kerbrute漏洞的示例，其中攻击者在Active Directory域中搜索现有用户。
caster@kali:~/kerberos-research$ ./kerbrute userenum --dc dc01.myownsummer.org -d myownsummer.org usernames.txt
__ __ __
/ /_____ _____/ /_ _______ __/ /____
/ //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
/ ,< / __/ / / /_/ / / / /_/ / /_/ __/
/_/|_|\___/_/ /_.___/_/ \__,_/\__/\___/
Version: v1.0.3 (9dad6e1) - 05/18/24 - Ronnie Flathers @ropnop
2024/05/18 21:10:43 > Using KDC(s):
2024/05/18 21:10:43 > dc01.myownsummer.org:88
2024/05/18 21:10:44 > [+] VALID USERNAME: [email protected]
2024/05/18 21:10:44 > [+] VALID USERNAME: [email protected]
2024/05/18 21:10:44 > Done! Tested 22 usernames (2 valid) in 0.591 seconds
Kerberos User Enumeration (kerbrute)
用户枚举（kerbrute）
Abundance of AS-REQ packets on the air
空中广播中的AS-BACK数据包
This number of AS-REQ packets in a few seconds is an anomalous behavior in the network. The following signature can be written on this to track anomalous AS-REQ within the network.
在几秒钟内出现如此多的AS-BACK数据包是网络中的一种异常行为。可以在其上写入以下签名，以跟踪网络中的异常AS-BACK。
alert udp any any -> any 88 (msg:"Kerberos High Rate of KRB-AS-REQ, Possible User Enumeration/Bruteforce Attack"; content:"|a1 03 02 01 05 a2 03 02 01 0a|"; threshold:type limit, track by_src, count 10, seconds 30; sid:100000; rev:1;)
alert – indicates that an alert will be generated when the rule is triggered;
alert -表示触发规则时会产生预警;
udp – indicates that the rule applies to UDP traffic;
udp -表示该规则适用于UDP流量;
any any -> any 88 – the rule will apply to any source IP address and port and any target IP address on port 88, which is the default port for Kerberos
any any -> any 88 -该规则将应用于任何源IP地址和端口以及端口88上的任何目标IP地址，端口88是TCP的默认端口
msg:"Kerberos High Rate of KRB-AS-REQ, Possible User Enumeration/Bruteforce Attack" – a message when a rule is triggered. Indicates a high frequency of KRB-AS-REQ requests, which may indicate user enumeration or a bruteforce attack;
msg:"Kerberos High Rate of KRB-AS-REQ, Possible User Enumeration/Bruteforce Attack" -触发规则时的消息。表示KRB-AS-IPSec请求频率高，可能表示用户枚举或暴力破解攻击;
content:"|a1 03 02 01 05 a2 03 02 01 0a|" – byte sequence indicating that this is a KRB-AS-REQ packet;
content:"|a1 03 02 01 05 a2 03 02 01 0a|" -指示这是KRB-AS-MBMS分组的字节序列;
KRB AS-REQ header bytes KRB AS-REQ报头字节
threshold:type limit, track by_src, count 10, seconds 30:
threshold – indicates the thresholds for triggering the rule;
threshold -表示触发规则的阈值;type limit – limit on the number of triggers;
type limit -限制触发次数;track by_src – track by source (number of requests from each source);
track by_src -按源跟踪（每个源的请求数）;count 10 – triggers if the number of requests exceeds 10;
count 10 -如果请求数超过10则触发;seconds 30 – time period for tracking requests (30 seconds);
seconds 30 -跟踪请求的时间段（30秒）;
sid:100000 – unique signature identifier;
sid:100000 -唯一签名标识符;
rev:1 – signature version indicating its revision.
rev:1 -签名版本，表示其修订版。
Verify the operation of this signature:
验证此签名的操作：
caster@kali:~/kerberos-research$ sudo suricata -c /etc/suricata/suricata.yaml -r kerbruteusernum.pcap
i: suricata: This is Suricata version 7.0.3 RELEASE running in USER mode
i: threads: Threads created -> RX: 1 W: 4 FM: 1 FR: 1 Engine started.
i: suricata: Signal Received. Stopping engine.
i: pcap: read 1 file, 64 packets, 10435 bytes
Kerberos user enumeration detection
用户枚举检测
This is how you can detect Kerberos user enumeration/bruteforce using the Suricata signature.
这就是如何使用Suricata签名检测恶意用户枚举/暴力破解。
Outro
In this research, I demonstrated the capabilities of Suricata signatures to detect attacks on Active Directory.
在这项研究中，我展示了Suricata签名检测Active Directory攻击的能力。
