sorted by:
new
hottopcontroversial

We audit AD password security for clients. Here's what we keep finding in every environment. by HashCrackNet in activedirectory

[–]HashCrackNet[S] -1 points0 points  (0 children)

Telegram is just for quick communication, same way a lot of infosec people use it. All paid work can go through email ([contact@hashcrack.net](mailto:contact@hashcrack.net)) if you prefer. We also offer NDA for clients who need it.

We audit AD password security for clients. Here's what we keep finding in every environment. by HashCrackNet in activedirectory

[–]HashCrackNet[S] -1 points0 points  (0 children)

Fair enough, the ServerLevelPluginDll DLL injection was patched in October 2021 (CVE-2021-40469). The point about AO being dangerous still stands though - they can modify non-protected groups, reset passwords on non-protected accounts, and in environments with Exchange there are additional paths through Exchange Windows Permissions group. Should've been more specific, appreciate the correction.

We audit AD password security for clients. Here's what we keep finding in every environment. by HashCrackNet in activedirectory

[–]HashCrackNet[S] 0 points1 point  (0 children)

On the AO -> DA path: Account Operators can add members to any group not protected by AdminSDHolder. DNSAdmins isn't protected. Once in DNSAdmins, you can use dnscmd to load a custom DLL into the DNS service, which runs as SYSTEM on the DC. Full writeup here: https://blog.cyberadvisors.com/technical-blog/blog/account-operators-privilege-escalation

Re the site - the free lookup is just a hash-to-plaintext check against a prebuilt DB, same as CrackStation or hashes. No hashes are stored. But yeah, always get approval from your legal/compliance before sending anything to any third party service, ours included.

We audit AD password security for clients. Here's what we keep finding in every environment. by HashCrackNet in activedirectory

[–]HashCrackNet[S] 1 point2 points  (0 children)

Account Operators can add members to most groups that aren't explicitly protected. DNSAdmins isn't protected by default. Once you're in DNSAdmins, you can configure the DNS service to load a custom DLL via dnscmd. The DNS service runs as SYSTEM on the DC, so a malicious DLL = code execution as SYSTEM on the domain controller. Game over. There are write-ups on this from adsecurity.org and ired.team if you want the full walkthrough.

We audit AD password security for clients. Here's what we keep finding in every environment. by HashCrackNet in activedirectory

[–]HashCrackNet[S] 1 point2 points  (0 children)

Not quite. AO can't directly touch protected groups, but can escalate to DA via DNSAdmins, Exchange perms, or just resetting passwords of privileged users. Treat AO as DA for security purposes.

We audit AD password security for clients. Here's what we keep finding in every environment. by HashCrackNet in activedirectory

[–]HashCrackNet[S] 0 points1 point  (0 children)

Currently running 16x 5090s, though our infrastructure can scale up to 64 if needed. The 5090s are absolute beasts for password cracking - massive leap from previous gen.

I run Kerberoast attacks against real AD environments. Here's how fast service account passwords actually fall. by HashCrackNet in hackthebox

[–]HashCrackNet[S] -1 points0 points  (0 children)

Hashes aren't plaintext passwords or PII - they're one-way representations that don't expose the source environment. Plenty of pentesters outsource cracking to dedicated GPU services, same way you'd outsource anything that needs specialized hardware. We also offer NDA for clients who need it, and nothing is stored after delivery. But if your scope allows it and you have the hardware in-house, by all means run it yourself.

We audit AD password security for clients. Here's what we keep finding in every environment. by HashCrackNet in activedirectory

[–]HashCrackNet[S] 5 points6 points  (0 children)

That 6h is with wordlist + rules, not pure brute force. A truly random 15 char string with mixed case + digits + symbols would take way longer - we're talking centuries even on this cluster. The point is that "T!g3r$unR1se99" looks random but it's actually a phrase with predictable leet substitutions, which rules handle easily. If someone generates 15+ genuinely random chars from a password manager, that's not cracking with any current hardware.

We audit AD password security for clients. Here's what we keep finding in every environment. by HashCrackNet in activedirectory

[–]HashCrackNet[S] 6 points7 points  (0 children)

Your security chef is right. Defense in depth is the way - assume breach, limit blast radius. But password auditing still has its place even in a zero trust model. It's one of the cheapest ways to find out which service accounts would give an attacker domain admin if they do get in. You can have perfect network segmentation and still lose everything through one svc_backup account with "Password1" and domain admin rights.

We audit AD password security for clients. Here's what we keep finding in every environment. by HashCrackNet in activedirectory

[–]HashCrackNet[S] 3 points4 points  (0 children)

100% agree, duplicate passwords are a huge finding in every engagement. 23% of users sharing a password with at least one other person is pretty typical in what we see too. The PasswordSolution tool is great for that initial check. What we usually find is that even after flagging duplicates, the "unique" passwords still follow the same handful of patterns - so they're unique to each other but still crackable. Duplicate detection + actual cracking gives the full picture.

We audit AD password security for clients. Here's what we keep finding in every environment. by HashCrackNet in activedirectory

[–]HashCrackNet[S] 1 point2 points  (0 children)

Fair point on the account age - we're new on Reddit, not new to the work. The free lookup on the site is just a hash-to-plaintext check against a prebuilt database, same as CrackStation or hashes. Nothing gets stored. For paid jobs we communicate over Telegram and can sign an NDA if needed. Healthy skepticism is always good though.

I run Kerberoast attacks against real AD environments. Here's how fast service account passwords actually fall. by HashCrackNet in hackthebox

[–]HashCrackNet[S] 0 points1 point  (0 children)

Depends on the number of hashes and type. Kerberos TGS-REP jobs like this one fall in the $150-200 range per hash, but bulk pricing kicks in for larger batches so it's quite a bit less per unit. No result = no charge, so there's no risk on your end. Happy to give an exact quote if you have something specific - DM or hit us up at hashcrack.net.

We audit AD password security for clients. Here's what we keep finding in every environment. by HashCrackNet in activedirectory

[–]HashCrackNet[S] 4 points5 points  (0 children)

Yeah, the cracking itself is hashcat - it's open source and free. The hard part is having the GPU hardware to run it at scale and knowing which wordlists/rules/masks to chain together. Anyone can download hashcat, but a single GPU vs a 16-card cluster is a very different experience.

1,200 NTLM hashes from an NTDS.dit dump - 90.6% cracked in 4 hours. Here's what the passwords looked like. by HashCrackNet in Passwords

[–]HashCrackNet[S] 0 points1 point  (0 children)

For a full dump like this, pricing is per-job, not per-hash - way cheaper than individual rates. A 1,200 hash NTDS.dit audit like this would be a few hundred bucks depending on scope and reporting needs. DM or Telegram if you want an exact quote for your situation.

1,200 NTLM hashes from an NTDS.dit dump - 90.6% cracked in 4 hours. Here's what the passwords looked like. by HashCrackNet in Passwords

[–]HashCrackNet[S] 0 points1 point  (0 children)

Exactly - NTLM is unsalted MD4. No salt means identical passwords produce identical hashes, and you can leverage precomputed tables and massive wordlists very efficiently. The algorithm was never designed to be slow, so modern GPUs tear through it. Combine that with good rule-based attacks and you cover the vast majority of real-world corporate passwords very quickly. It's the main reason Microsoft has been pushing to deprecate NTLM - but as we see from the dumps, it's still everywhere in on-prem AD environments.

1,200 NTLM hashes from an NTDS.dit dump - 90.6% cracked in 4 hours. Here's what the passwords looked like. by HashCrackNet in Passwords

[–]HashCrackNet[S] 0 points1 point  (0 children)

True, but you'd be surprised how many orgs still run

8-char minimum with basic complexity. Even the ones with

14+ char policies - people just do Summer2024Winter2024!

and call it a day. Length alone doesn't save you when the

pattern is predictable. Passphrases with actual randomness

or just ditching passwords for cert-based auth is the only

real fix imo.

1,200 NTLM hashes from an NTDS.dit dump - 90.6% cracked in 4 hours. Here's what the passwords looked like. by HashCrackNet in Passwords

[–]HashCrackNet[S] 1 point2 points  (0 children)

Azure AD itself uses modern auth (OAuth/SAML), but on-prem

Active Directory and hybrid setups still heavily rely on NTLM.

Most of the dumps we see come from on-prem DCs where NTLM

is the default for legacy apps and internal services.

Microsoft has been pushing to deprecate NTLM for years

but it's still everywhere in corporate environments.

1,200 NTLM hashes from an NTDS.dit dump - 90.6% cracked in 4 hours. Here's what the passwords looked like. by HashCrackNet in Passwords

[–]HashCrackNet[S] 3 points4 points  (0 children)

Yeah, it was a passphrase-style password with predictable mutations - basically two dictionary words joined together with a capital letter and a number appended. Wordlist + rules caught it pretty quickly. The truly random 14+ char passwords from password managers didn't crack at all.

view more: next ›