How Do Hackers Actually Get In? A Beginner's Map of Real Attack Paths

The mental image most people have of a hacker — someone typing furiously at a terminal, cracking encryption in real time — is almost completely wrong.

Real intrusions are slower, more methodical, and more boring than the movies suggest. They exploit predictable human behaviour, misconfigurations that have existed for years, and the natural complexity of systems that were never designed with adversarial use in mind.

More importantly: most successful attacks don't require sophisticated techniques. They follow well-documented, repeatable paths that security teams have studied, named, and published — and that organisations still fail to close because they're defending against the cinematic version of hacking rather than the operational reality.

This article maps the real attack paths. Not theoretical vectors from a textbook — the actual sequences that show up in breach reports, incident investigations, and penetration testing engagements.

The Fundamental Reality That Changes How You Think About This

Before mapping the paths, one mental model shift matters more than anything else:

Attackers don't look for the most sophisticated way in. They look for the easiest way in.

The barrier to entry for most attacks is not technical skill — it's patience and tool access. Automated scanning tools identify vulnerable services. Credential stuffing tools test leaked passwords at scale. Phishing toolkits generate convincing emails from templates. A significant percentage of real-world intrusions require no original research or novel technique.

This means that the organisations that get breached are not necessarily the ones with the most complex attack surfaces. They're the ones with the most predictable weaknesses in the most accessible positions.

The second reality: most breaches are not single-step events. They're kill chains — sequences of actions that move an attacker from initial access to their ultimate objective. Getting in is step one of a process that has many more steps.

Attack Path 1: Phishing — The Entry Point That Never Gets Old

Phishing is the most common initial access technique in real breaches — not because defenders don't know about it, but because it bypasses technical controls by targeting humans.

What actually happens in a phishing intrusion:

1. The attacker selects a target organisation and researches it using public information — LinkedIn for employee names and roles, company website for email format patterns, recent news for context that makes emails more convincing.

2. A convincing email is crafted. Modern phishing emails impersonate internal IT communications, HR notifications, Microsoft/Google account alerts, or vendor communications. They include the target's name, reference real events, and use logos and formatting that match the impersonated sender.

3. The email contains either a malicious link (to a credential harvesting page) or a malicious attachment (that installs malware on open).

4. One employee clicks. Their credentials or a malware payload is delivered. Initial access is established.

5. The attacker now has a foothold in the network — they can escalate privileges, move laterally to other systems, and work toward their ultimate objective.

Why it still works: Technical controls can block known malicious domains, suspicious attachments, and signatures. They cannot reliably block a convincing email from a newly registered domain that has never appeared in a threat feed.

The defences that actually matter: Multi-factor authentication (MFA) prevents credential theft from becoming account access — even if someone steals your password, they can't log in without the second factor. Phishing-resistant MFA (hardware keys, passkeys) is more effective than TOTP codes, which can be phished in real time.

Attack Path 2: Credential Stuffing

Credential stuffing attacks test large volumes of username/password combinations against web applications. The credentials come from data breaches — lists of emails and hashed or plaintext passwords leaked from previous compromises.

The scale of available breach data is staggering. Have I Been Pwned tracks over 12 billion compromised accounts. When a major service is breached, the credentials are typically sold on dark web markets, then distributed freely, and automated tools test them against every major service within hours of the breach.

Why credential stuffing succeeds: People reuse passwords. A user who has the same password on a compromised forum and on your application gives attackers access to your application without any attack on your application directly.

Effective defences:

• Enforce or strongly encourage password uniqueness (breach monitoring integrations like HaveIBeenPwned API check submitted passwords against known breaches)
• Require MFA for sensitive operations
• Rate limit authentication attempts per IP and per account
• Alert users on new device/location logins

async function checkBreachedPassword(password) {
  const sha1 = crypto.createHash('sha1').update(password).digest('hex').toUpperCase();
  const prefix = sha1.slice(0, 5);
  const suffix = sha1.slice(5);
  
  const response = await fetch(`https://api.pwnedpasswords.com/range/${prefix}`);
  const text = await response.text();
  
  const isBreached = text.split('\n').some(line => {
    const [hashSuffix] = line.split(':');
    return hashSuffix.toUpperCase() === suffix;
  });
  
  return isBreached;
}

Attack Path 3: Exposed Services and Default Credentials

Automated scanners continuously probe the public internet for exposed management interfaces, default credentials, and known vulnerable services.

Shodan and Censys index every publicly accessible service. An organisation that leaves a database management interface, admin panel, or developer tool accessible on the public internet without strong authentication will be found and probed within hours.

Common exposures:

• Database admin interfaces (phpMyAdmin, Adminer, MongoDB Compass web UI) with default credentials
• Developer tools left running (Jupyter notebooks, Redis without password, Elasticsearch without authentication)
• VPN and remote access software with known vulnerabilities that were never patched
• Exposed cloud storage buckets with public read/write access

The attack is not sophisticated: Attacker scans for MySQL on port 3306. Finds it open. Tries root:root, root:password, admin:admin. Gets in. Extracts the database. Sells it or deploys ransomware.

Defence: Network segmentation keeps databases off the public internet. Default credentials are changed on every deployment. Patch management ensures known vulnerabilities are closed before they appear in active exploit kits.

Attack Path 4: SQL Injection — Still in the Wild

SQL injection has been documented, studied, and defended against for over two decades. It still shows up in breach investigations regularly, particularly in older applications and in codebases built by teams that learned to build web apps from tutorials that didn't teach security.

// Vulnerable — never do this
const results = await db.query(`
  SELECT * FROM users WHERE username = '${username}' AND password = '${password}'
`);

// Safe — parameterised query
const results = await db.query(
  'SELECT * FROM users WHERE username = $1 AND password = $2',
  [username, password]
);

Modern ORMs use parameterised queries by default. The risk today is in raw query construction, migration scripts, and legacy codebases that predate widespread ORM adoption.

Attack Path 5: Broken Access Control

Access control failures are the number one category in OWASP Top 10 2021. They occur when applications fail to enforce restrictions on what authenticated users are allowed to do.

Common patterns:

• Direct object reference: changing GET /api/invoices/123 to GET /api/invoices/124 returns another user's invoice
• Role escalation: a regular user can access admin endpoints because authorization checks are missing or incomplete
• Function-level access control: an endpoint that should only be available to admins is accessible to any authenticated user

// Missing authorization check — vulnerable
app.get('/api/user/:userId/data', async (req, res) => {
  const data = await getUserData(req.params.userId);
  res.json(data);
});

// With authorization check
app.get('/api/user/:userId/data', async (req, res) => {
  // Verify the requesting user can access this userId's data
  if (req.user.id !== req.params.userId && !req.user.isAdmin) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  
  const data = await getUserData(req.params.userId);
  res.json(data);
});

The Kill Chain: Putting It Together

Real attacks rarely use a single technique. The kill chain for a significant breach typically involves:

1. Initial access — phishing, credential stuffing, or exploiting an exposed service
2. Establish persistence — install malware or create a backdoor account
3. Privilege escalation — move from a limited account to admin/root privileges
4. Lateral movement — access other systems on the network using stolen credentials
5. Data discovery — identify valuable data (customer records, financial data, IP)
6. Exfiltration — extract data to attacker-controlled infrastructure
7. Impact — deploy ransomware, sell data, use infrastructure for further attacks

Defenders who focus only on preventing initial access leave the rest of the kill chain open. Effective security assumes some initial access will succeed and focuses on detection and containment at each subsequent stage.

The organisations that suffer the worst breaches are not necessarily the ones with the weakest perimeters. They're the ones with no visibility inside the network — so when initial access succeeds, the attacker moves through the kill chain unchecked for weeks.

Logging, monitoring, and anomaly detection are not optional. They're the difference between a contained incident and a news story.