If you ask someone outside cybersecurity what a hacker does, they'll probably conjure an image of someone hammering away at keyboards, bypassing firewalls, and cracking passwords like an evil genius. Oh, and they’ll be wearing a hoodie. Hackers are apparently always cold, especially around their necks.
The truth? That perception has done more harm than good.
We’ve mythologized hackers to the point that people see them as unstoppable villains with access to the most sophisticated and esoteric technology capabilities. As a result, it’s easy to feel like stopping them is just too hard. Too complicated. Too expensive. Like the only thing you can do is hope you’re not the target this time.
But the reality is far different.
Hackers don’t actually do much hacking. They usually just log in.
The moment a threat actor gets their hands on privileged credentials, the “hacking” stops and the impersonation begins. They operate like any other authorized user—but with a very different agenda. And in far too many environments, that access is wildly overpermissive. What should’ve been a narrow, task-specific authorization becomes a supercharged launchpad for lateral movement, privilege escalation, and data exfiltration.
They move laterally. Escalate privileges. Access core systems. And exfiltrate data with ease. And to admins and the security teams, it all looks legitimate and normal. Do you ever wonder why news coverage usually mention that an attack, “...occured seven months ago but was just recently discovered by the company.”?
That’s the secret no one wants to admit: most of the damage happens after access is granted. Not during a breach. Not through some dazzling zero-day exploit. But once they’ve tricked, phished, or bought their way into your environment—often with credentials no one ever thought to question.
And if your access model isn’t built around that truth, you’re probably not prepared.
Key Points
- Most attacks start with compromised credentials—not exploits.
- Identity-based intrusions now make up more than 2/3 of breaches, fueled by infostealers, phishing, and AI-generated payloads.
- Once inside, attackers use legitimate access to escalate privileges, move laterally, and exfiltrate data specifically because of implicit trust based on authentication and IP address.
- Modern environments amplify risk with identity sprawl, legacy systems, and binary trust models.
- Traditional PAM tools can’t enforce dynamic, policy-driven controls across hybrid, multi-cloud stacks, or from multiple contexts.
Zero Trust privileged access is the fix—but only when applied architecturally, not bolted on.
The Real Job is Getting In
Hackers have learned that identity is the soft underbelly of enterprise security, and access is the path of least resistance—not because the tech is weak, but because humans are. We’re terrible at managing complex authentication, so we take shortcuts: reusing passwords, hardcoding secrets into scripts, and choosing convenience over security. That’s the real vulnerability attackers exploit.
Why spend time discovering and weaponizing a zero-day in a hardened service when someone on your payroll is one click away from running an infostealer payload that dumps their session tokens, browser-stored credentials, or SSH keys?
Why waste effort bypassing firewall rulesets when the real gold—domain admin credentials, hardcoded secrets in scripts, or API tokens with overprivileged scopes—are sitting unmonitored on a developer laptop or stale in a forgotten Git repo?
Most attackers understand that identity is infrastructure. It’s a control plane. And it’s often misconfigured, over-permissive, or fragmented across legacy systems and cloud providers that don’t speak (or even abide by) the same policy language.
The journey and process are basic, and they mirror the activity used by legitimate and non-legitimate users alike. It’s just that legitimate users won’t intentionally do harm. It looks like this:
- Initial access is achieved through phishing, token theft, browser credential scraping, or marketplace-purchased logins.
- Lateral movement uses tools like Cobalt Strike, Impacket, Rubeus, or built-in system protocols (e.g., WMI, PowerShell Remoting, RDP) to pivot inside the network without tripping alarms.
- Privilege escalation comes from poorly scoped IAM roles, unsecured credential vaults, or hybrid environments where on-prem AD trust relationships extend into Azure AD without proper segmentation.
- Persistence is maintained through scheduled tasks, golden tickets, cloud access keys, or federated session hijacking.
That’s a pretty linear progression of activity, and if you look behind it, you see that attackers aren’t breaching a system. Rather, they’re abusing identity systems as designed, often without triggering any detections. Because once they’re authenticated, they’re trusted. And trust is the problem.
Credential-based compromise is scalable, repeatable, and reliable, especially in enterprises where identity governance hasn’t kept pace with infrastructure modernization (examples include credential injection attacks, credential stuffing, and leaked credentials). The attacker doesn’t need root access on day one. They just need any foothold in the graph of access relationships. The rest is enumeration, privilege chaining, and policy failure.
So no, they’re not clawing through the perimeter. They’re logging in, enumerating roles, and using your own access infrastructure against you.
Identity-based attacks are now the standard playbook.
According to the 2025 Verizon DBIR, credential abuse is the #1 initial access vector, responsible for 22% of breaches, outpacing both vulnerability exploitation and phishing. Meanwhile, 60% of breaches involve a human element; these include credential misuse, phishing, and social engineering—often made worse by poor identity governance and weak access controls.
Attackers don’t need to break in when credentials are available for sale, exposed in Git repos, or harvested from poorly secured endpoints. In fact, 54% of ransomware victims had their domains appear in credential dumps, and 40% had corporate emails compromised—a direct path to unauthorized privileged access.
The Unit 42 Cloud Threat Report reinforces this, revealing that IAM misconfigurations are the #1 cause of cloud security incidents. Over 80% of cloud exposures stem from over-permissioned identities or improperly scoped roles, turning what should be isolated blast zones into full-environment compromise.
Attackers know that identity is the softest layer of enterprise infrastructure—and most environments still treat access as a one-time gate, not an ongoing trust decision.
Hackers have evolved their playbook, and they're betting on one thing: you’re not protecting access nearly as well as you think. Mark Hughes, IBM’s Global Managing Partner for Cybersecurity Services, sums it up aptly:
“Cybercriminals are most often breaking in without breaking anything – capitalizing on identity gaps overflowing from complex hybrid cloud environments that offer attackers multiple access points.”
And that’s the uncomfortable truth: You can invest in advanced threat detection. You can patch vulnerabilities on a tight schedule. But none of it matters if the attacker logs in with real credentials.
What This Looks Like Inside the Enterprise
Modern enterprise environments span a complex array of systems, including hybrid infrastructures, multi-cloud architectures, and API-first applications. And in those environments, where it is common to have hundreds of applications operating and sharing data, identity sprawl has become normal, and it brings an array of risks, including overprivileged access, poor credential hygiene, and governance fragmentation across platforms.
Organizations are juggling a mix of operational issues, including:
- Full-time employees, contractors, and third-party vendors—each with distinct access needs but often overlapping entitlements.
- Legacy systems that can’t support SAML, OIDC, or modern MFA, yet still house sensitive data or critical operational logic.
- Cloud-native services that resist clean federation and policy enforcement across identity providers, leading to fragmented governance.
- Hardcoded credentials and secrets embedded in shell scripts, CI/CD pipelines, and configuration files—often with broad scopes and no lifecycle management.
The problem is that most enterprises operate without the agility to address these complex, agile environments. As a result, they become increasingly vulnerable. The Unit 42 Cloud Threat Report offers a stark picture of what ultimately happens:
- 83% of organizations have hard-coded credentials in their source control systems, and 85% store them in VM user data—making lateral movement trivial once access is gained.
- Over-permissive identity is pervasive. Roles with broad privileges, such as creating users or editing IAM policies, are often granted where only minimal access was needed.
- 76% of organizations don't enforce MFA for cloud console users, and 58% don't enforce it for root or admin accounts—leaving cloud control planes exposed to brute-force and credential stuffing attacks.
- 66% of cloud storage buckets analyzed contained sensitive information like PII or financial data, and 61% lack access logging, further obscuring malicious access and exfiltration paths.
We all like to use the “front door” analogy, but the truth is–and these stats bear out– that in these environments, a single compromised identity is doing more than opening a door, it’s providing a detailed map.
Once an attacker steps in, even with just a low-privileged credential, they can enumerate cloud IAM policies, query directory structures, inspect trust relationships, and leverage internal discovery mechanisms to pivot laterally and escalate access. Through a basic understanding of how IT environments work, it starts to become like pattern recognition, especially since enterprises rely on similar tech stacks. Hackers get to business efficiently by doing the following:
- Scan for IAM misconfigurations like privilege escalation paths (e.g., iam:PassRole, sts:AssumeRole) and overly broad resource grants.
- Exploit unmonitored service accounts and stale access tokens to chain together privilege.
- Target orchestrators, control planes, and infrastructure-as-code pipelines that often sit outside of real-time access controls but hold the keys to everything downstream.
And they do all of it under the auspices of a “legitimate” identity—an authenticated session, a trusted user, an unchallenged role.
The problem?
Most enterprise access models are still binary. Once authenticated, the system assumes the user is trustworthy, often for the duration of the session—regardless of context, behavior, or risk indicators. That trust model might have sufficed in perimeter-centric environments, but in distributed, identity-as-the-perimeter environments, it’s a liability.
You don’t need to break encryption or exploit zero-days when the system will hand you the keys for simply presenting the right token. You don’t need to bypass firewalls when you can inherit an IAM role that gives you s3:* across prod buckets. And you certainly don’t need to “hack” when you can log in and just use the infrastructure.
This is the reality defenders face. And it’s why access can no longer be a static decision made at login time—it must be a continuously evaluated trust contract. Because in an identity-first security landscape, the real attack surface isn’t your network. It’s your permissions graph.
Zero Trust Privileged Access: Continuous Security Required
If your identity infrastructure is being used against you, then the answer isn’t more perimeter—it’s a complete rethink of how access is managed, verified, and constrained.
A zero trust approach gives enterprises, irrespective of size or infrastructure type, a better way to address the incumbent issues of access. That said, this is not simply, “we turned on MFA,” or “we rotate passwords weekly.” What’s needed is a solution that treats access as a dynamic, policy-driven, and least-privilege system of controls that operates continuously and contextually.
Assume attackers will get in. Assume credentials will be compromised. Then design your access strategy to limit what they can do next.
Zero Trust Privileged Access means:
- Never trusting access just because someone logged in.
- Continuously verifying identity, context, and device posture.
- Applying granular, just-in-time access to sensitive resources.
- Extending modern authentication like MFA—even to legacy systems.
- Logging, auditing, and reviewing everything.
Legacy access solutions treat this all like security theater, as they’re designed more for checkboxes than actual control. They can demonstrate compliance in a static audit, but they can’t enforce security in a dynamic environment. They assume perimeter boundaries still exist, rely on brittle role hierarchies, and often can’t touch the systems that matter most: legacy infrastructure, ephemeral workloads, or multi-cloud services with inconsistent identity layers.
These systems fall back on a state of rigidity in the face of complexity, overly trusting by default, and are ultimately blind to threats that present with seemingly valid credentials. The moment an attacker blends in, they break down.
The recourse is Zero Trust—but only when its principles are applied as an architectural correction, not a feature retrofit or branding exercise.
Too often, Zero Trust is misunderstood as a set of tools or a checkbox framework. The reality is that it’s a fundamental shift in how trust, identity, and access are managed across the entire environment. It means rethinking authentication not as a one-time gate but as a continuous, context-aware process. It means treating internal traffic with the same skepticism as external connections, enforcing least privilege not just at the network level but across data, infrastructure, and APIs. And it demands uniform policy enforcement across disparate systems—on-prem, cloud-native, and legacy alike.
When applied correctly, Zero Trust transforms identity from a vulnerability into a control plane. But that only happens when it’s embedded into the architecture itself—evaluating access dynamically, brokering trust in real time, and minimizing blast radius by design.
In short, Zero Trust isn’t something you buy. It’s something you architect.
StrongDM delivers Zero Trust Privileged Access that goes beyond theory and into architecture by enforcing real-time, granular controls across every system, protocol, and environment. We provide secure access for any principal—human, workload, or automation agent—to any resource, legacy or modern, without ever exposing credentials. Access is continuously verified based on identity and context, and unsanctioned privileged actions are blocked before they happen. All of it built for coverage without compromise.
Book a demo to see StrongDM in action.
StrongDM Architecture Overview
