The Active Directory Security Mistakes I See in Every Slovenian Company

I've been doing penetration tests for Slovenian companies for over 5 years now. Active Directory environments are my specialty - and honestly, they're the reason I have such a high success rate. Not because I'm some genius hacker, but because the same mistakes keep appearing in almost every company I test.

Let me share what I actually find when I get inside a Slovenian corporate network. These aren't theoretical attacks from security conferences. These are the real misconfigurations that give me Domain Admin access, usually within the first day of testing.

The "We Have LAPS" Illusion

I love it when companies tell me they've implemented LAPS (Local Administrator Password Solution). They say it with such confidence, like they've solved the local admin problem forever.

Then I run a simple LDAP query and find:

• 30% of computers don't have LAPS deployed at all
• The LAPS password is readable by "Domain Users" because someone misconfigured the ACLs
• Old computers that were "supposed to be decommissioned" still use the same local admin password from 2018

In one engagement last year, I compromised a server that the IT team swore was "completely isolated." It had the same local admin password as 47 other machines. That password? The company name followed by "2019!"

Service Accounts: The Gift That Keeps Giving

Kerberoasting is supposed to be well-known by now. Every security vendor talks about it. Yet in my last 20 engagements, I successfully Kerberoasted credentials in 18 of them.

The pattern is always the same:

1. I find service accounts with SPNs
2. I request their tickets (any domain user can do this)
3. I crack the passwords offline - usually within minutes
4. These service accounts have Domain Admin rights "because the application needed it"

My favorite was a backup service account with the password "Backup2020!". It had Domain Admin rights, and the password hadn't been changed in 4 years. The IT team's defense? "We couldn't change it because we didn't know what would break."

This is why I always recommend Group Managed Service Accounts (gMSAs). The password is 240 characters, rotates automatically, and you never have to manage it manually. But explaining this to companies that are "too busy" to implement it properly? That's the real challenge.

The NTLM Relay Playground

SMB signing is disabled by default on Windows workstations. Most Slovenian companies never change this. This means I can:

1. Sit in the network with Responder running
2. Wait for authentication requests (or coerce them with PetitPotam)
3. Relay those credentials to other machines
4. Get shells on servers without cracking a single password

The fix is simple - enable SMB signing. But when I mention this in reports, the response is often "it will slow down file transfers." Yes, by a negligible amount. But apparently, that's worse than me having full access to your file servers.

LDAP signing is even worse. I'd estimate less than 10% of Slovenian companies have it enabled. This means I can relay credentials to LDAP and modify Active Directory objects directly. In one test, I added myself to the Domain Admins group within 15 minutes of starting.

BloodHound Reveals Everything

Every penetration test, I run BloodHound. Every time, it shows me attack paths that the IT team had no idea existed.

Common findings:

• Help desk users can reset passwords for IT admins (who can reset passwords for Domain Admins)
• A marketing user has GenericAll rights on a computer object (leading to RBCD attack)
• Nested group memberships that give unexpected admin access
• Service accounts that are members of 15 different groups "just in case"

The worst part? These attack paths often exist because someone needed temporary access 3 years ago and nobody cleaned it up. AD permissions accumulate like technical debt, except most companies don't even know they have this debt.

The Domain Controller Configuration Hall of Shame

In Slovenian companies, I regularly find:

Print Spooler running on DCs: This service should never run on domain controllers. It enables PrinterBug attacks that can coerce the DC to authenticate to my machine. Combined with NTLM relay, this is often game over.

Unconstrained delegation: Some applications "require" it, so IT enables it without understanding the implications. Any time a Domain Admin logs into a machine with unconstrained delegation, I can capture their TGT and impersonate them.

No tiered admin model: The same account that resets user passwords also manages domain controllers. When I compromise one workstation, I can often escalate to Domain Admin within hours because admins reuse their credentials everywhere.

The Password Problem

Password policies in Slovenia seem stuck in 2005. I commonly see:

• 8 character minimum (crackable in seconds)
• 90-day expiration (leading to Password1!, Password2!, Password3!...)
• No breached password checking
• The company name as part of the password for "brand consistency"

When I run password spraying attacks, I almost always find accounts with passwords like:

• [CompanyName][Year]!
• Geslo123! (yes, "Geslo" means "Password" in Slovenian)
• Ljubljana2024
• Summer2024!

One company had a policy that passwords must start with a capital letter and end with a number. Guess what pattern 80% of their users followed?

The Azure AD Gap

More Slovenian companies are moving to hybrid environments, but they're making new mistakes:

• Azure AD Connect servers treated like normal workstations
• No conditional access policies
• Legacy authentication still enabled (allowing password spray attacks)
• No MFA for admin accounts because "it's inconvenient"

I've seen companies invest heavily in on-premises security while leaving their Azure environment wide open. The cloud isn't automatically secure - it requires the same attention to configuration.

What Actually Works

After years of finding the same issues, here's what I tell companies to prioritize:

1. Enable SMB and LDAP signing. Yes, everywhere. The performance impact is negligible compared to the security gain.
2. Implement LAPS properly. This means deploying it to ALL machines and restricting who can read the passwords. Audit this regularly.
3. Use gMSAs for service accounts. Stop using regular accounts with static passwords. gMSAs solve this problem completely.
4. Run BloodHound on yourself. Before I find those attack paths, you should find them. Clean up the unnecessary permissions.
5. Implement tiered administration. Admin accounts for workstations should never touch servers. Server admins should never touch domain controllers. This limits the blast radius of any compromise.
6. Disable Print Spooler on DCs. Just do it. Whatever printing need you think you have, there's a better solution.
7. Modern password policy. 15+ characters, no complexity requirements (they don't help), block breached passwords, ban company-related terms.
8. MFA everywhere. Especially for admins, especially for remote access, especially for cloud services.

The Real Problem

The technical fixes aren't that hard. The real challenge is organizational. Companies don't budget for AD security reviews. IT teams are overwhelmed with daily operations. Security is seen as a cost center, not a business enabler.

Then one day, ransomware hits, and suddenly there's budget. Except now it's for incident response, not prevention.

I write these findings in every report, and I know most of them won't be implemented until there's a breach. That's the frustrating reality of security consulting in Slovenia. But I keep writing them, because every company that does listen is one less victim.

If you're reading this and recognizing your own environment, you have two choices: fix it now while you have time, or fix it later when you're explaining to your CEO why ransomware just encrypted all your domain controllers.

I know which option I'd choose.