13.01.2025
21 min
1101
In this paper, we will be discussing why common network security measures provide little or no true sense of security for networks in use today. You will learn how attackers can gain complete, silent access to a system and its most valuable assets while providing their victims with no evidence of what occurred. The author will present an entirely different type of network monitoring solution that provides the ability to visually follow each step taken by an attacker as they attempt to penetrate your network; the focus will be on actual examples of raw network traffic analysis, not theory.
Hi there, HackYourMom users! We’re going deep into how secure Active Directory really is today. There’s no secret about it; the central hub of any large business network based on Microsoft products is the Kerberos Authentication Protocol. With every login to your company PC, every file share over a network folder, and with each new connection made to your company’s internal SQL Server Database or Portal — all of those activities generate a very heavy, steady flow of Kerberos communications.
Therefore, as far as any professional pen tester (or just a hands-on hacker) is concerned, Kerberos is the first place to go when you want to break in. If you can break Kerberos, then you essentially have the key to the whole domain — which makes you basically a “god” within the framework of that network.
Traditionally Blue Teams have built their defensive walls using Windows logs and expensive Endpoint Detection Response (EDR) solutions. When a Blue Team sees an Event ID 4768 (Ticket Request) or Event ID 4771 (Authentication Failure) in their Security Information and Event Management (SIEM), they immediately begin investigating. Doesn’t it seem as if this method is somewhat antiquated and filled with holes?
This article will demonstrate that the “magic” behind Threat Hunting lies within the analysis of raw network packets and not within endpoint events. Further, we’ll explain how to use open-source intrusion detection systems such as Suricata IDS to identify attackers before they’ve established themselves in your network.
Firstly, let’s be honest: Why is it a dead-end to rely entirely on Event Logs and Agent-based Solutions? At first glance, Microsoft seems to provide a robust auditing solution. However, when looked at in reality, things are far different.
They’re simple to delete. An attacker who achieves Local Admin Privileges or greater will likely be able to clear the Event Log(s) via something such as Clear-EventLog -LogName Security. Thus, the trail goes cold; you may never find out what occurred prior.
Malware can disable these logs. Many modern rootkits and advanced implants (and even basic Cobalt Strike configurations) can either intercept ETW (Event Tracing for Windows) calls or unhook the API function(s) utilized by your EDR. Your EDR may report that all is well, while the attacker is quietly extracting hashes from the LSASS process memory.
Latency is always present. There are numerous reasons why there is a delay in reporting of logs. First, the logs must be written to disk, then collected by an agent, then transmitted over the network to a solution such as Splunk or ELK, then indexed, then correlated, then finally an alert is generated. The time it takes to generate this type of alert can range anywhere from minutes to hours. For exfiltrating sensitive information, that amount of time is ample.
Context is absent. A Windows log reports a dry fact: “Someone tried to login.” The Windows log does not tell you how the network packet was constructed, nor does it tell you what flags were set during construction, nor does it tell you what application requested the authentication.
Network packets do not lie. Once a packet has traversed your switch and has made its way onto a TAP Interface or SPAN Port, it cannot be deleted once it has been created. Therefore, either the packet existed on the wire — or it did not exist on the wire.
To identify anomaly behavior you have to know what “normal” behavior looks like. Kerberos behaves similarly to a VIP pass system at an exclusive social event. All of this activity revolves around the KDC (key distribution center), where the KDC usually runs on Domain Controllers. There are two processes in this authentication cycle.
The Authentication Service (AS) acts as the primary gatekeeper (ticket booth) at the entrance of the party. When you provide your credentials (username/password), the ticket booth provides you with a generic access wristband (TGT – Ticket Granting Ticket). The exchange occurs through the use of AS-REQ packets (client requests) and AS-REP packets (server responses).
The Ticket Granting Service (TGS) acts as the security guard near the restricted area or backstage zone. When you show the security guard your generic access wristband (TGT) and ask to be granted access to a particular service (such as a file server), the security guard will then provide you with a service-specific wristband (service ticket) for that particular resource. The exchange for this activity utilizes TGS-REQ and TGS-REP packets.
Typically, all of this traffic flows through TCP/88 and UDP/88 and is encapsulated in ASN.1 binary format. While it may seem dry, by analyzing the ASN.1 structure, you can deconstruct these packets down to nearly their molecular level.
Next, we’ll examine the “idealized” process that attackers use to exploit the “ideal” process for malicious purposes in real world attacks.
A hacker’s goal when gaining access to a network for the first time (for instance via a phishing campaign or a weak application) is to initially operate in the dark. What they most need is a list of valid usernames. They will use applications such as Kerbrute instead of trying to guess them.
Kerbrute sends many AS-REQ requests to a Domain Controller, however, they send these requests without PA-DATA (the Pre Authentication Block). Therefore, they do not include a password.
If the requested username does not exist on the domain, the KDC returns with the error code PRINCIPAL UNKNOWN.
If the username exists on the domain, the KDC returns with PREAUTH_REQUIRED. This indicates the KDC recognizes the account, however, requires the correct password.
The only real issue here is that the account lockout policy is never triggered since no incorrect password has been entered. Thus, hackers have complete control over their environment during the “stealth phase”.
How would you identify this in Wireshark? Typically, if there is a pattern of bytes in a Kerbrute generated request that could be fed into an ASN.1 Decoder, you can find this in the hex dump of the request.
a1 03 02 01 05 a2 03 02 01 0a ... 6b 72 62 74 67 74
a1 03 02 01 05– this is a Kerberos v5 protocol label.
a2 03 02 01 0a– this is an indication that the message type is 10 (i.e. AS-REQ).
6b 72 62 74 67 74– this is stupidly the string krbtgt in ASCII encoding.
Since the utility sends dozens of requests per second, we can write a rule for Suricata that will respond exclusively to the abnormal rate of such packets from a single IP address.
Signature:
alert udp any any -> any 88 (
msg:"[UDP] High Rate of Kerberos AS-REQ, Possible Enumeration";
content:"|a1 03 02 01 05 a2 03 02 01 0a|";
content:"|6b 72 62 74 67 74|"; fast_pattern;
threshold:type limit, track by_src, count 5, seconds 10;
sid:100000; rev:1;
)
If five such packets arrive from the same IP address within ten seconds, that’s definitely not a human. Time to raise the alarm.
The first thing that happens after discovering a valid username is trying to crack its password. This process can be done via an AS-REQ request; however, a key piece of information is added in this instance: the Pre-Authentication Block PA-DATA (encrypted timestamp). Using the encrypted timestamp as an input to an encryption function with a password taken from the attackers dictionary and sending that request to the KDC will result in either an error message if the password is incorrect or successful authentication if the password is correct.
The reason why this is easily distinguishable from the previously described attack (Enumeration) is based on the byte level. An additional indicator has been added into the HEX Dump for this type of request: PA-ENC-TIMESTAMP (type 2):
a1 03 02 01 02
START_TEXT But there’s a twist. Classic brute-force attacks, which involve attempting many passwords against one account will immediately trigger an account lockout. Therefore, smarter hackers are using Password Spraying techniques to attempt one common password (such as Winter2026!) on hundreds if not thousands of individual user accounts.
Therefore, the detection rule for brute-force or spraying must be revised accordingly:
alert tcp any any -> any 88 (
msg:"[TCP] Intensive Kerberos Bruteforce Attack Detected";
content:"|a1 03 02 01 05 a2 03 02 01 0a|";
content:"|6b 72 62 74 67 74|"; fast_pattern;
content:"|a1 03 02 01 02|"; distance:0;
threshold:type threshold, track by_src, count 20, seconds 5;
sid:100002; rev:1;
)
We included a check for the presence of PA-DATA and increased the trigger threshold (count 20 within 5 seconds). Brute force attacks generate a lot of “noise.” If someone is incorrectly guessing the correct password that many times in succession, they’re likely not an accountant that simply flipped the caps lock key.
Attack Three: Kerberos Ticket Stealing & Service Enumeration
Kerberoasting is a bit more sophisticated than the previous two attacks. The goal of the attack is not the average user, but rather the “service” accounts that are tied to specific SPNs (Service Principal Names) — such as the account used by an MS SQL Server. Often these service accounts have very strong, yet very old passwords that have never been changed.
The attacker has a valid TGT obtained via the first attack. They then send a request to the Domain Controller for a service ticket for the MS SQL server. The Domain Controller responds with a TGS-REP packet. It’s at this point that the magic occurs — part of the ticket is encrypted using the hash of the service account’s password. The attacker captures the packet and uses it as input for an off-line brute force attack against the service account’s password hash. Common tools used for this type of attack include Rubeus.
Another reason why Kerberoasting is particularly interesting is that attackers will often intentionally ask the KDC to issue the ticket using the older RC4-HMAC encryption algorithm (etype 23). Since RC4 is so much easier to crack on GPU systems vs. AES-256, using this type of encryption helps the attackers crack the hashes faster. When viewed as a protocol traffic capture, this appears as an encryption down-grade request.
When reviewing your traffic and notice a TGS-REQ packet that specifically asks for etype 23, that is a huge red flag.
Another common method used today in modern pentesting. This is a targeted attack on a user account which had been configured with the pre-authentication requirements removed (typically due to legacy system configurations) — i.e., the DONT_REQ_PREAUTH flag is set in Active Directory settings.
The attacker needs no prior access to the network and simply sends an empty request to the server asking it to generate an AS-REP. Because pre-authentication is disabled, the KDC will respond to the request. Again, part of that response will be encrypted with the user’s password hash and the attacker can then use this information with Hashcat and wait for the password to crack.
Impacket’s scripts are the most commonly used tool to perform this type of attack; specifically, GetNPUsers.py.
What does Impacket’s fingerprint in network traffic look like? The Impacket’s scripts have a consistent pattern. The script always has the same combinations of flags — FORWARDABLE | PROXIABLE | RENEWABLE — and asks for weak RC4 encryption. In HEX, the resulting sequence looks similar each time:
a0 07 03 05 00 50 80 00 00 a1
This makes it possible to write a detection signature to catch it:
alert tcp any any -> any 88 (
msg:"Suspicious AS-REQ Packet, Possible AS-REP Roasting (Impacket)";
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:!"|a1 03 02 01 02|";
sid:100009; rev:1;
)
Notice the clever trick: the exclamation mark !"|a1 03 02 01 02|" placed before the content. This means we are looking for packets where the pre-authentication block (PA-DATA) is simply missing. That’s because AS-REP Roasting only works against accounts where pre-authentication is disabled.
Alright, we’ve written some solid detection rules. But where should they actually run? If you deploy an IDS on your laptop inside a Wi-Fi network, you won’t see anything useful. You need a proper packet capture architecture.
SPAN ports (Port Mirroring). Configure your core switches so they mirror all traffic going to the domain controllers’ ports onto a dedicated monitoring port. Connect your Suricata server to that port.
Network TAPs. These are hardware “wiretaps” inserted directly into the fiber or copper link between the switch and the server. They guarantee 100% traffic capture without putting additional load on the switch. This is the ideal option for the truly paranoid.
Network analysis is essentially an X-ray for your domain. You can see protocol structures, encryption algorithms, and the real behavior of requests — things an attacker simply cannot hide or erase.
Minimum steps for a Blue Team starting tomorrow morning:
Deploy an IDS. Set up Suricata or Zeek, at least in front of your domain controllers. Without this, you’re basically playing roulette blindfolded.
Kill RC4. Search your domain configuration for any references to the outdated RC4 encryption and disable it via Group Policy (GPO). Leave only AES-128 and AES-256 enabled.
Audit pre-authentication settings. Scan Active Directory for accounts with “Do not require Kerberos preauthentication” enabled. If you find any, disable it immediately — but first make sure you won’t break some ancient barcode scanner or legacy system still running in a warehouse somewhere.
Build a test lab. Don’t blindly copy-paste detection rules. Spin up a test VM with Active Directory, run Kerbrute against it, capture the traffic, and tune the signatures for your environment so you don’t drown in false positives.
Attackers are getting smarter every day. They know how to bypass antivirus tools and wipe their tracks from servers. But there is one fundamental limitation they cannot escape: no one can compromise a network without generating network packets.
Be smarter. Analyse the traffic.
