During an external red team engagement, one of the first things I expect to find is more attack surface than the client initially realizes.
That was certainly the case in a recent assessment.
The organization had multiple domains and a diverse technology footprint: applications hosted across Azure, AWS and on-premises infrastructure, production and non-production environments, APIs, web applications, and WordPress-based marketing sites. As we expanded our reconnaissance, we identified additional subdomains and applications that added to an already sizable external footprint.
From an attacker’s perspective, there was plenty to investigate.
We started with the usual external attack-surface discovery and vulnerability assessment activities: subdomain enumeration, network and service enumeration, web application testing, vulnerability scanning and manual validation. Nmap, Nessus, Nuclei, Burp Suite, Nikto and SQLmap were among the tools used during different stages of the assessment.
But despite the size of the attack surface, we weren’t getting what we ultimately wanted. There was no obvious vulnerability that translated into a reliable path to initial access and, subsequently, the internal network. That is when the assessment became more interesting.
When the Obvious Attack Paths Don’t Work
One of the things I have learned from red team engagements is that an attacker isn’t particularly interested in whether a vulnerability scanner has reported a critical finding.
The attacker is interested in one thing: Can I get in?
If exploiting an internet-facing application isn’t working, the next question shouldn’t necessarily be which scanner to run next. It should be what other avenues an attacker could realistically use.
We had already learned quite a bit about the organization’s infrastructure. So we shifted some of our attention away from vulnerabilities in systems and toward the people and identities associated with those systems. That led us to investigate exposed credentials associated with the organization’s domains.
The results were surprising.
We identified more than 400 credentials associated with the organization’s domains in leaked credential datasets.
At first, a number like that sounds catastrophic. But numbers can be misleading. A credential appearing in a breach dataset doesn’t mean that an attacker can still use it. The password may have been changed, the account may have been disabled, or the data itself may be years old. So the interesting question wasn’t how many credentials we found.
It was:
How many of them still worked, and what could they access?
A leaked credential is not necessarily a compromised account
We validated the credentials where it was appropriate to do so within the scope of the engagement. Many of the credentials were no longer usable. Others were associated with accounts on third-party services commonly used by employees. Some, however, were still valid, that changed the risk considerably.
Among the services associated with the credentials were platforms such as GitLab, LinkedIn and Dropbox. These are not insignificant services from an attacker’s perspective. Depending on the account and what information it has access to, compromising such an identity could provide useful intelligence, access to data, or opportunities for further attacks.
But there was a problem for us as attackers, the accounts had multi-factor authentication enabled. The credentials were valid. The passwords were known. But the passwords alone weren’t enough. The authentication process required another factor that we did not have. From a red team perspective, the attack path stopped there. And that was a good thing.
This is Where MFA Proved its Value
It is easy to talk about MFA in abstract terms. Security teams have been recommending it for years. Organizations have rolled it out across email, VPNs, cloud platforms and SaaS applications. It is now considered a fundamental identity-security control. But seeing it stop an attack path during a real assessment is a useful reminder of why it matters.
The sequence was essentially:
The credential had already been compromised.
MFA couldn’t change that.
What it changed was what the attacker could do with the compromised credential. That distinction is important. Security controls don’t always prevent the initial failure. Sometimes their job is to prevent one failure from becoming a much bigger one.
- A password can be leaked.
- An employee can reuse a password.
- A third-party breach can expose credentials.
- An old database can resurface years later.
The organization cannot always control whether a credential eventually appears somewhere outside its environment. It can, however, control whether that credential is sufficient to authenticate.
Then We Found Applications Without MFA
The assessment became considerably more interesting when we encountered credentials associated with applications owned by the client.
Unlike the third-party accounts, some of these applications did not enforce MFA.
In those cases, the exposed credentials allowed us to gain access to the web applications. This was arguably more valuable than simply reporting that hundreds of credentials had been leaked.
It demonstrated the difference between credential exposure and credential exposure combined with weak authentication controls.
The same underlying problem a compromised password produced two very different outcomes depending on how the application handled authentication.
That is the part of the engagement that stayed with me. The problem wasn’t simply that credentials had leaked It would be easy to write this assessment up as a story about leaked passwords. I don’t think that is the most useful takeaway.
The more important finding was the inconsistency in how different applications responded to the same threat.
Some services had an additional authentication barrier. Some didn’t.
That matters because large organizations rarely have a perfectly uniform application environment. There may be a central identity provider protecting most corporate applications, while an older application has its own login mechanism.
- A SaaS platform may enforce MFA by default, while an internally developed application doesn’t support it.
- Production may have strong authentication controls, while a test or development environment has weaker ones.
- An application may support MFA but leave it optional.
From an organization’s perspective, these may look like separate systems. From an attacker’s perspective, they are all potential entry points.
We Traditionally Think of External Attack Surface in Terms of:
- Domains and subdomains
- IP addresses
- Open ports and services
- Cloud resources
- Web applications
- APIs
- VPNs
- Remote access services
All of those remain important. But there is another layer that is often treated separately:
Identity
- Who are the employees associated with the organization?
- Which accounts do they have?
- Which applications can those accounts access?
- Have their credentials appeared in previous breaches?
- Which accounts are protected by MFA?
- Which applications still rely solely on passwords?
- What happens when an employee’s credentials are exposed?
These questions are just as relevant to an external attacker as questions about ports and technologies.
Why Credential Monitoring Should be Continuous
Finding hundreds of exposed credentials during a red team assessment also raises a practical question: How long were those credentials exposed before anyone knew about them?
Organizations shouldn’t have to wait for a penetration test to discover that corporate identities have appeared in breach datasets.
Credential exposure monitoring can provide an additional layer of visibility into the organization’s external risk. When a corporate credential is discovered, the objective shouldn’t simply be to notify the employee.
The organization should determine:
- Is the account still active?
- Is the password still valid?
- Where can the identity authenticate?
- Is MFA enforced?
- Are there other authentication paths that bypass MFA?
- Has the password been reused?
- Does the account have privileged access?
- Are there suspicious authentication events?
- Should sessions or tokens be revoked?
The response should be proportional to the potential impact, but the underlying principle is simple:
A leaked credential should be treated as a security signal, not merely an employee-awareness issue.
MFA is essential, but consistency matters more than checkbox compliance. There is a subtle lesson here for organizations that have already implemented MFA.
It is tempting to say: “We have MFA.”, But that statement doesn’t tell an attacker very much.
A better set of questions would be:
- Which applications have MFA
- Which accounts are exempt?
- Which legacy applications don’t support it?
- Can MFA be bypassed through another authentication flow?
- Are development and test environments protected to the same standard?
- Can an attacker reset the password or change the MFA factor without strong verification?
- Are service and privileged accounts covered?
The more useful model is:
What Red Teams Can Teach Us That Scanners Can’t
One of the reasons I value red team engagements is that they force us to think beyond individual vulnerabilities. A vulnerability scanner might tell us that an application has a particular weakness. A red team asks whether that weakness can actually contribute to the attacker’s objective.
The Takeaway
We started this engagement looking at domains, applications, cloud infrastructure and exposed services. Eventually, some of the most interesting findings were not vulnerabilities in those systems at all – They were identities.
Modern external attack surface, an attacker doesn’t necessarily need to exploit your infrastructure if they can simply authenticate to it. And when a password is already in the attacker’s hands, MFA may be the difference between having a credential and having access. That is exactly what we saw during this engagement. The credentials were leaked. The attack still failed. And, in this case, that was the security control working exactly as intended.
