It may just be imprecise writing, but this is very misleading. The stat is that 4.18 B hashes can be computed per second, not cracked. Computing a hash means converting a given input into its hash. Cracking a hash means starting from the given hash and determining what the input must have been. To crack a given hash you have to iterate over the input space and compute all their hashes (barring other exploitable weaknesses).

So, sure you can "crack" 4.18 B hashes per second, as long as you don't care that the hashes you are "cracking" are not the one you're interested in.

Note that since the 2022 update KB5019964, AES is the default for all AD accounts that did not have the administrator explicitly set a different encryption scheme. However, administrators may have done that on your domain in the past, because back in the day, the default encryption scheme was not even RC4, but DES, which is even worse. Some people therefore set everything to RC4 by hand, before AES was introduced as an option.

The allowed encryption types are set via the msDs-supportedEncryptionTypes attribute on each individual AD account. This property is a 32 bit bitmask, where 8 is AES128, 16 is AES256, and any other bits set are garbage encryption schemes. However, if the attribute is set to 0, the account reverts to the default, which ever since the aforementioned patch has been 24 (AES128|AES256).

Anyway, the following Powershell (run with elevated permissions on the domain!) lists you all insecure user accounts:

    Get-ADUser -Filter 'msDs-supportedEncryptionTypes -ne 0 -and msDs-supportedEncryptionTypes -ne 8 -and msDs-supportedEncryptionTypes -ne 16 -and msDs-supportedEncryptionTypes -ne 24'

    Get-ADComputer -Filter 'msDs-supportedEncryptionTypes -ne 0 -and msDs-supportedEncryptionTypes -ne 8 -and msDs-supportedEncryptionTypes -ne 16 -and msDs-supportedEncryptionTypes -ne 24'

TGS are (AES or RC4) encrypted with the NT password hash of the service account they are associated with. If you have a weak service account password, then TGS can be cracked to obtain the service account's password. A lot of times admins will create service accounts that have way more permissions than required (e.g. they make them a DA) which can lead to an immediate privilege escalation. Sometimes they also use regular user accounts for service registration instead of designated service accounts, and user accounts tend to have weaker passwords. To make it worse, any low privilege Active Directory account can request a TGS for any service, even if they are not allowed to access that service.

Even if the service account is lower privilege, this can enable a silver ticket attack. https://www.crowdstrike.com/en-us/cybersecurity-101/cyberatt...

There are multiple mitigations for this:

1. Use managed or group managed service accounts instead of manually managed ones where possible. This ensures that account passwords are long, strong, and rotated regularly. If you are going to provision service accounts manually, give them very strong passwords.

2. Apply the principle of least privilege and only assign service accounts the privileges they need. Avoid placing them in high privilege groups.

3. Disable RC4 in your environment if possible via Group Policy.

4. Monitor for RC4 ticket requests. AES-encrypted tickets are the default these days. https://adsecurity.org/?p=3458

5. Create a honeypot service account: https://adsecurity.org/?p=3513

There is a somewhat similar attack against TGTs called ASREPRoasting: https://book.hacktricks.wiki/en/windows-hardening/active-dir...

> Identifying devices limited to RC4 is a critical step but has historically been a tricky problem to solve. However, a recently discovered "feature" in 4768 events can help you identity such devices. […] As a result, 4768 events can be used to identify devices that only support RC4.

* https://techcommunity.microsoft.com/blog/coreinfrastructurea...

Also:

> While DES has long been considered insecure, CVE-2022-37966 accelerates the departure of RC4 for the encryption of Kerberos tickets. If you have not explicitly assigned an algorithm to accounts, then AES will be used in the future. You can use PowerShell to determine which accounts are vulnerable to weak encryption.

* https://blog.sonnes.cloud/find-active-directory-accounts-con...

There are certainly disadvantages to legacy support being 'too good'.

This is what I understood: the corporate network needs to be able to connect ordinary users on some random employee's work computer, to privileged services elsewhere on the (generally insecure) network, securely. The idea is that the server sends the client some kind of encrypted token, the decryption of which — when the system is properly configured — would require some long, random passphrase beyond mortal comprehension. The user's machine stores the passphrase so that secure passphrases can be used by the mere mortal users, and automates the internal connection. But if a user gets compromised from outside the network, an attacker could explicitly request and exfiltrate one of the tokens, and run brute force attacks on it locally to the attacker; and for historical reasons, the system is likely to be poorly configured, such that the necessary passphrase is weak enough to be susceptible to this. Then the attacker uses the decrypted token to escalate access.

My question is: why can't the attacker just direct the compromised machine to connect to the service normally? Or else, where did I lose the plot?

Their ubiquitous systems have been notoriously insecure for decades.

They are one of the highest revenue firms on the planet.

It is going to take strict liability for software developers before we all pull up our socks and put an end to this nonsense. When it is a marketing advantage to produce insecure software, what else can fix our industry?

I despair

Their ubiquitous systems have been notoriously insecure for decades.

They are one of the highest revenue firms on the planet.

It is going to take strict liability for software developers before we all pull up oursocks and put an end to this nonsense. When it is a marketing advantage to produce insecure software, what else can fix our industry?

I despair

Did he not get the memo that this is not allowed?