Most serious incidents do not begin with malware or exploits.
They begin with a valid login.
Once attackers authenticate, their objective changes.
The question is no longer how to get in, but how far this access can go.
In many organizations, the answer is: much further than expected.
Why this matters at leadership level
From a board perspective, a single compromised account should be containable.
In practice, it often becomes a gateway to multiple systems, teams, and decisions.
This happens because:
1. Access rights accumulate over time
2. Trust between systems is implicit
3. Convenience outweighs containment
4. Monitoring assumes good intent after login
The business risk is not the initial compromise.
It is the expansion that follows.
The common paths from one account to many
Across industries, access expansion follows predictable patterns.
Most incidents rely on:
1. Credential reuse across systems
2. Over-privileged user or service accounts
3. Cached credentials on servers
4. Single Sign-On trust chains
5. API keys with broad scope
6. Weak internal segmentation
These are design and governance issues, not zero-day failures.
Tools attackers actually use to expand access
The tools involved are rarely sophisticated.
Most are built-in, widely available, or already approved for IT use.
Credential reuse and validation
Attackers often test whether one login works elsewhere.
Tool: CrackMapExec
crackmapexec smb 10.0.0.0/24 -u user -p password
This does not exploit anything.
It tests assumptions about trust.
Cached credential harvesting
Once inside one system, attackers look for credentials already stored there.
Tool: Mimikatz
sekurlsa::logonpasswords
Attacking systems use cached credentials to maintain workflow and effectiveness; therefore, it provides yet another area of vulnerability that an attacker can exploit.
Directory and identity visibility
Directory services often reveal more than intended.
Native commands
net group "Domain Admins" /domain
query user /server:fileserver
These actions look like routine administration.
They rarely trigger alerts.
Mapping hidden trust relationships
Attackers want paths, not passwords.
Tool: BloodHound / SharpHound
SharpHound.exe -c All
This reveals access chains leadership never approved explicitly.
Token and session reuse
Modern environments rely on tokens, not passwords.
Tokens often bypass authentication entirely.
export AWS_ACCESS_KEY_ID=AKIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...
aws sts get-caller-identity
Token lifetime decisions directly affect blast radius.
Single Sign-On as an access multiplier
SSO simplifies work.
It also centralizes failure.
az ad signed-in-user show
One compromised identity can unlock email, HR, finance, and cloud platforms without new logins.
API keys and pipeline secrets
API keys often have no expiration and broad permissions.
printenv | grep KEY
A single exposed key can unlock multiple services silently.
Living-off-the-land movement
Attackers avoid custom tools altogether.
schtasks /create /sc minute /mo 30 /tn "Updater" /tr cmd.exe
Nothing new is installed.
Everything already exists.
Real-world examples
Example 1: VPN infiltrated - a user's credentials have been collected through phishing and were used to log on to file servers. Consequently, the admin's cached credentials were also collected allowing the hacker to have complete access to the company's domain in a matter of hours.
Example 2: Cloud IAM account hacked - a single IAM cloud user had their credentials hacked, which then led to the hacker gaining access to CI/CD pipelines. The CI/CD pipeline credentials were stored as secrets and contained production credentials, leading to the compromise of the company in multiple environments.
Example 3: Exploitation of helpdesk accounts - the helpdesk login for HP's executives would typically only allow resetting the password during business hours; however, the hackers took advantage of this privilege to reset the accounts of several executives. The hackers did not install malware on the affected systems and gained access to the executive accounts for email, finance and documents.
Example 4: Payroll information obtained through a compromised SaaS account - a marketing team member who used a SaaS account was hacked and used their same identity to connect to HP's internal SSO service. There is a high level of trust in the SSO token used to log into the payroll system, consequently allowing the hacker access to sensitive information related to HP's payroll.
Example 5: CI/CD pipelines became a channel for hackers to gain access to a developer's account - hacker compromised a developer's account and extracted the secrets from the CI/CD pipeline, thus providing them with indirect access to HP's production environment.
Example 6: Ransomware recovery neutralized through exploiting backup admin access rights - hacker obtained a backup admin's credentials and acquired the ability to delete or restore a company snapshot, thus neutralizing the recovery process and keeping investigators from discovering that their systems were infected with ransomware.
Why defenses often miss this
Most security controls focus on stopping entry.
After login:
1. Activity looks legitimate
2. Commands are familiar
3. Access follows approved rules
Attackers succeed by staying inside those rules.
What actually reduces the risk
Organizations that limit blast radius focus on structure, not alerts.
Effective measures include:
1. Clear privilege boundaries, reviewed regularly
2. Short-lived credentials and tokens
3. Separation between user, admin, and service identities
4. Monitoring relationships, not just actions
5. Regular testing of “what one login can reach”
These are leadership decisions with technical execution.
Questions boards should ask
1. What systems can a single employee account reach today?
2. Which accounts bypass approval workflows?
3. How quickly can access be revoked everywhere?
4. Are CI/CD, backup, and service accounts treated as high risk?
5. When was the last full identity path review conducted?
The answers usually surface more risk than expected.
Attackers do not need many logins.
They need one that opens doors.
Reducing access multiplication does not slow the business.
It limits surprise, damage, and recovery time when mistakes happen.
