The MFA That Wasn’t (Part 2)
Lares, a Damovo Company
Empowering Organizations to Maximize Their Security Potential.
How weak login architecture and missing multi-factor controls turned access into a compromise
This is Part 2 of a recent Lares engagement.
In Part 1, we demonstrated how mismatched credentials, weak password patterns, and user enumeration enabled working logins for QA, sales, finance, and the founder, without sending a single phishing email or exploiting a technical misconfiguration.
In this post, we follow the next step: how those same logins gave us various privilege levels/roles in the CRM platform.
No MFA. No questions asked.
It started with a self-service portal
The first place we tested credentials was on a company’s externally accessible MDM portal. It only required a username and password, no MFA.
That alone would be a significant problem. But the portal did more.
Invalid usernames returned a standard "invalid credentials" message
Valid usernames that appeared to be service and/or location oriented accounts returned 401 errors, confirming the account existed
Valid logins exposed the full email address tied to the short-form username
In some cases, their mobile carrier, the device (model + version), the IMEI number, and in some cases, recent location tracking was visible inside the portal dashboard
More importantly, this portal validated credentials against the internal Active Directory.
So every test didn’t just hit a web app - it hit core identity infrastructure.
Behind the scenes: MDM Portal > Identity Authentication> Active Directory
The MDM portal wasn’t acting alone. It was using an identity broker, which then passed authentication checks to the company’s internal AD database.
That meant every login attempt was an internal check dressed up as an external login.
And because credentials worked here, we tested them elsewhere.
The Microsoft portal that asked for nothing
Next, we attempted to use the login function on the organization’s main site, which redirected authentication through Microsoft Online (MSOL). We used the same accounts we had validated through the MDM.
They logged in. Immediately. No MFA prompt. No device challenge. Just success.
These were not sandboxed accounts. They were employee accounts typically wired into client portals, document repositories, and business applications.
We weren’t escalating. We weren’t exploiting.We were just logging in to accounts that happened to have elevated privileges.
Token leaks: The CRM handed over too much
After authenticating through MSOL without MFA, we were redirected to the internal CRM.
Here’s where it got worse.
When we decoded the returned JWT (Bearer token), it included:
Full name
Department name and department number
Employee ID
Account ID
Some of this may have been required for app integration. But none of it needed to be handed to the browser. This is the kind of unnecessary exposure that attackers use to pivot, impersonate, or fingerprint user access paths.
What we accessed
Using nothing but valid credentials, we gained access to:
Internal customer invoices and billing history
Downloadable PDFs containing full banking data, account numbers, routing numbers, and SWIFT codes
Internal and client contact details
CRM-level identity metadata via decoded tokens
No MFA. No segmentation. Just form fields, session cookies, and excessive trust.
What stood out
The biggest lesson wasn’t the missing MFA. It was how much the organization assumed the login was the boundary.
Everything was built on the idea that once a user logs in, they belong there. That logic works fine until someone logs in who shouldn’t be able to.
And in this case, they didn’t need to bypass controls.They just needed to blend in with everyone else.
What You Should Take Away
1. MFA needs to be everywhere
Not just for admins. Not just for VPN. Everywhere. If a user can access client data, that login needs a second factor.
2. Login pages should never leak validation behavior
HTTP response codes, email reveals, and user-specific feedback all support enumeration
3. SSO and identity federation need proper boundaries
Identity authentication linked to internal AD without safeguards creates a lateral path by design
4. JWTs should not leak unnecessary user metadata
Employee IDs, department numbers, and internal account identifiers should never be sent client-side unless absolutely necessary.
5. Sensitive data needs more than a login screen
If a document contains financial records or PII, a password alone should never be enough.
Final Thoughts
This wasn’t a phishing campaign. It wasn’t malware.
But it was an exploit.
The access we gained was the result of weak MFA, poor identity boundaries, and an architecture that trusted too much, and tied it all back to a vulnerable Active Directory environment.
Once we had that foothold, the rest unfolded exactly as it would for a real attacker:
Real credentials
Working login paths
Overexposed tokens
No enforcement
The story here isn’t about privilege escalation.
It’s about how the system handed us access, and how everything downstream trusted what came next.
Ready to find out what your infrastructure is actually exposing?
Author: Andrew Heller - Marketing Manager, Lares
Special thanks to Jonathan Wiggins for his contributions to this engagement and the insights shared throughout this series.