Employee Behavior Is the Breach (Part 1)
Lares, a Damovo Company
Empowering Organizations to Maximize Their Security Potential.
How weak passwords, reused credentials, and an overly helpful login portal opened the door
This is Part 1 of a two-part breakdown of a recent Lares engagement.
In this first post, we walk through how our team went from mismatched credential data to high-value internal access, without phishing, scanning, or exploiting a single technical flaw.
In Part 2, we’ll cover how those initial footholds led to privilege escalation, internal data exposure, and full compromise, all due to missing MFA and weak identity federation controls.
It started with mismatched data
We had two datasets.
One was a list of cracked passwords and short usernames (jsmith) from a previous internal engagement. The other was a list of public-facing emails in first.last@company.com format.
No roles. No targets. Just fragments. We aligned the formats, using a script to identify likely matches, found 3, and started testing logins.
We didn’t check who they belonged to. We didn’t need to. The logins worked. That was enough.
Bad habits are better than exploits
Once we had working credentials, we reviewed the cracked password list in the same way an attacker would, looking for patterns rather than names.
We looked for:
Passwords like oregon on regional accounts
Simple structures like CarNameYEAR
Long passwords that met complexity rules but were still guessable
And most telling, predictable year rotation
One account stood out. It was one of the three initial email-to-username matches we had tested successfully. When we revisited that account the next day, the password no longer worked. It had been changed. For curiosity's sake, we incremented the year; EXAMPLE2024 became EXAMPLE2025.
That worked.
No phishing. No cracking. Just a logical guess. This wasn’t a technical failure. It was a failure of awareness and habit.
This wasn’t brute force. This was behavioral profiling.
The login portal gave us everything
Next, we tested credentials against the company’s mobile device management (MDM) portal.
It was single-factor. No MFA. No CAPTCHA. No lockout. Just form fields and feedback.
And the feedback told us exactly what we needed.
Invalid usernames returned a generic “invalid credentials” message
Valid usernames and passwords for service or regional accounts returned an HTTP 403 code, indicating the account was real but not authorized for this portal
Valid, authorized user accounts logged in successfully and exposed the full email address tied to the short-form username
In some sessions, the portal also revealed device registration info and location data
This portal wasn’t just accepting credentials. It was giving structure to the data we already had. If we had started with only short-form usernames from internal sources, we could have used this interface to map them to full email addresses immediately.
That’s not a vulnerability in isolation, but it’s precisely how attackers chain small wins into access. Each bit of feedback, each error code, helped us refine the story.
What made this worse was what was happening behind the scenes.
The MDM portal was using a third-party Identity Provider to validate credentials against the company’s internal Active Directory. So, every login attempt didn’t just touch a public-facing application; it reached into the core identity infrastructure.
This wasn’t just an authentication point. It was an enumeration tool and a real-time confirmation engine for internal accounts.
So, where did this get us?
From scraps of data and user behavior alone, we gained valid access to:
QA personnel
Sales staff
Finance roles
The former CEO
No malware. No phishing. No noise. Just a login box, bad decisions, and an environment that trusted everything it saw.
What You Should Take Away
1. Long passwords help, but only if the structure isn’t predictable
Length improves resistance to cracking, but not if users revert to common formats like names and years. A long password, even if it contains multiple regular words found in a dictionary, is better than a 12-character password with alpha-numeric + special characters. $up3r$3kret! is not bad, but not great.
BlueChevyBeachTacosFishingMountainsRiversBBQ! is an example of a passphrase, which in this case is 48 characters, and would be tough to crack because of the length
2. Enumeration is still alive and well
Login portals that reveal subtle differences in response behavior give attackers a roadmap. Every status code is a clue. Every response helps refine targeting.
3. User behavior creates repeatable patterns
Awareness training that focuses on phishing and ignores password reuse or year rotation is missing the mark. Habits are more consistent than threats.
4. Monitoring didn’t stop it, but questions came later
Our activity didn’t trigger alerts in real time. Some accounts were flagged eventually, and internal teams did reach out to investigate. But by then, we had everything we needed.
Coming Next: What Happens After the Door Opens
In Part 2, we’ll show how that initial access was used to pivot into Microsoft login portals, internal financial data, and full client records. No second factor. No segmentation. Just a clear path forward.
What started with a cracked password ended with full compromise.
[Read Part 2 → Coming Soon]
Special thanks to Jonathan Wiggins for his contributions to this engagement and the insights shared throughout this series.