Multi-factor authentication (MFA) is often touted as a silver-bullet for preventing breaches, but it is only as good as the people using it. Without other compensating controls in place, a malicious actor could be one push notification away from your internal network. This is the story of how I went external-to-internal on an external network pentest through one user’s weak password, even when their account was configured to use MFA.
Weak passwords are still commonplace in 2024, and it’s easy to understand why. Few organizations want to foist robust password policies on their users, lest it become one more source of stress in their lives. For organizations that do require strict password policies, it puts additional strain on IT help desks for password resets when Bob or Alice forget their 16-character, must-include-uppercase-and-two-special-characters password. Help desks are often already underwater due to the rapid advance of technology and the continuous push to remote work. So, it’s understandable that some organizations are still allowing passwords that are only eight-to-twelve characters, with minimal complexity requirements.
Weak passwords equal weak security
Something I do on every single pentest is check for weak passwords. On an external pentest, it’s not always easy to compile an accurate list of users of an organization. We comb LinkedIn for employee names, check password breach databases for email addresses. Getting usernames is one thing, but validating them is completely different. In a list of 1,000 usernames, only a handful might be valid. Thankfully, for pentesters, Microsoft 365 Online has a user enumeration vulnerability which allows anyone to determine if a user account is valid. On this test, I got lucky. The customer was using Microsoft 365. Not only that, but 107 of the 280 total usernames that I gathered were valid. A substantial basis to begin password spraying.
Password spraying is when you test a list of accounts against weak or common passwords. My personal favorite archetype for these attacks is {season}{year}, but I’ve had success with local sports teams for guesses as well. Sometimes, a variation of the organization name with numbers or special characters works. Hopefully, when you spray a list of users, one of them has had their password recently reset by their IT team. I know from personal experience working a help desk that technicians will often reset a user’s password to something short and memorable. I also know from experience that if end-users aren’t forced to change their password after a reset, they’ll keep using it for as long as they can. A lot of users like short passwords. Who doesn’t? If it weren’t for hackers like me, I’d probably be tempted to use a weak password as well.
On this occasion, I got lucky again: a user was using Winter2024 as their password. I immediately tried logging into their organizational Microsoft Online account, only to have my hopes dashed. I saw a prompt for Duo MFA. Most pentesters are remiss to force a push to a user, especially if it’s for the only credentials they’ve compromised on the test; one ill-timed push can encourage a user to change their password and alert their security team. I put the credentials on the backburner while I looked for other methods of compromise. But when enumerating the web applications the customer had in-scope, a thought occurred to me. What if MFA wasn’t being required everywhere?
Catching the professor off-guard
The customer I was testing was a university. And it just so happened that the user I compromised was a member of their faculty: a professor. One of the webservers in-scope was a front-end application for a database of students at the university. I successfully logged in as the professor, and saw a goldmine of PII, all without needing an MFA push. The database had the full names of students, their grades, and the courses in which they were enrolled. What’s more, this database also had a schedule for the classes the professor was teaching. I saw that their first class of the day was scheduled at 10:30 AM the following day. I formulated a plan — a few minutes before the class started, when I imagined the professor would be plugging in their laptop, logging into school resources, and checking their email, I would send a push in the hope of catching the professor distracted.
The time came to put the plan into action. My finger hovered over the ‘Send Push’ button, knowing that if the professor thought it was fishy, they’d likely change their password immediately and I’d lose access. I hit the button, waited with bated breath — three seconds, four seconds. Too long, I thought. Then the screen refreshed, and I was looking at a message that said the push was accepted. I couldn’t believe it.
Being a pentester, I didn’t stop there. It’s one thing to gain access to a system, but it’s another to maintain access, at which point they have to drag you out kicking and screaming. I added a second device to this user’s Duo account: a phone number I controlled. I left the professor’s phone as the default, so the only thing that anyone would see at a cursory glance was a tiny drop-down icon next to the phone number. Without having to worry about timing subsequent MFA pushes, I began enumerating in earnest.
It turns out, the university had several hosts with port 389/TCP exposed to the public Internet — a port commonly associated with LDAP, a protocol used to query Active Directory. And I had valid Active Directory credentials. I used BloodHound and LDAPDomainDump to pull a complete list of users, computers, and groups from the Domain. These queries generate a ton of noise if defenders are watching. Half-expecting to get kicked out of the account, I watched as my tools dutifully enumerated the internal network. I now had a list of all the administrators in their domain — targets for further attacks, if I so desired.
I also discovered they had an open Remote Desktop Protocol (RDP) service exposed to the Internet. Domain users had to complete a multi-factor push to access the service, but that was no longer a problem with the compromised Duo account. The host using RDP was part of the university’s computer lab network, with access to numerous other hosts on the same network. It was at this point that I let the customer know I was in their internal network. All because of one weak password, for an account that wasn’t configured with any elevated access. An account that also used MFA to access resources.
See us after class
Attack chains like these show us why it’s so important to practice defense in depth. If the domain used a stronger password policy, I couldn’t have guessed the password. If excessive services weren’t exposed to the internet, I wouldn’t have gained internal access. And if the customer’s internal security solutions were more sensitive to network enumeration, the attack could’ve been stopped there. But above all, engagements like these show us why we sometimes need a pentester to demonstrate to us just how vulnerable we are.