L03 · Thinking Like an Attacker

Module 1: Security Foundations · ~20 min · Lesson 3 of 71

🎯 What you'll learn

• The seven stages of the Lockheed Martin Cyber Kill Chain, and where a defender can break each one
• What an attack surface is, and how to map one for a service on Kong and EKS
• Why attackers and defenders play by different rules, and where defenders actually have the edge

🔥 Why this matters

In 2014, attackers stole contact details for about 76 million households and 7 million small businesses from JPMorgan Chase. According to later press reports, they got in through one network server that had been missed when the bank rolled out two-factor authentication. A huge security budget, lost to one forgotten door. Attackers don't read your architecture diagram; they look for the door you forgot. This lesson teaches you to look for it first.

1. The attacker's plan: the Cyber Kill Chain

A bank robbery isn't one event: the crew cases the building, gets tools, gets in, opens the vault, and leaves. Interrupt any step and they go home empty-handed.

In 2011, Lockheed Martin researchers Hutchins, Cloppert, and Amin described intrusions the same way. Their Cyber Kill Chain is the seven stages an attacker must complete to reach their goal. Here it is against ExampleFin, a made-up financial API company, attacked by criminals after customer data.

 1 RECONNAISSANCE ......... research the target
      │ finds dev-api.example.com; its error pages
      │ print a library name and an old version
      ▼
 2 WEAPONIZATION .......... build the attack (on their own kit)
      │ pairs a public exploit for that version
      │ with a small backdoor program
      ▼
 3 DELIVERY ............... get the payload to the target
      │ one crafted HTTP POST to dev-api
      ▼
 4 EXPLOITATION ........... the bug runs the attacker's code
      │ code now runs inside a quote-api pod
      ▼
 5 INSTALLATION ........... stay in, even after a restart
      │ backdoor written to disk; a new IAM
      │ access key created with the pod's role
      ▼
 6 COMMAND & CONTROL ...... a remote-control channel
      │ backdoor calls home over HTTPS every 60 s
      ▼
 7 ACTIONS ON OBJECTIVES .. the real goal
        the pod's role can read an S3 bucket of
        "test data" copied from prod: 2M records out

A few terms from the diagram:

• Reconnaissance uses public sources: certificate logs, job ads, and a dev site that talks too much.
• Weaponization combines an exploit (code that abuses a vulnerability) with a payload (what runs afterwards). It happens on the attacker's machines, so you almost never see it.
• Delivery can be a phishing email, a malicious package, or, for APIs, just an HTTP request.
• Installation gives the attacker persistence: a foothold that survives restarts, redeploys, and password resets.
• Command and control (C2) is the channel for sending instructions and getting results back.
• Actions on objectives is whatever they came for: data, money, ransom, or a path to the next target.

2. Breaking the chain

The model's real point is defensive: the attacker must get every stage right; you must break one.

The original paper lists six responses: detect, deny, disrupt, degrade, deceive, and destroy. Day to day, you'll mostly detect, deny, or disrupt.

The earlier you break the chain, the cheaper the incident: a request blocked at stage 3 is a log line; a stage 7 catch is a breach notification. But later stages are your safety net. Patching will sometimes fail, and egress controls still stop the data leaving. This layering is defense in depth (L04).

Limits of the model. The Kill Chain was built for malware-driven intrusions. With stolen credentials, an attacker often skips weaponization and installation and just logs in; insiders skip most of the chain. So defenders also use MITRE ATT&CK, a far more detailed catalog of real attacker techniques (L61).

3. The attack surface

The attack surface is the sum of all the places where an attacker can try to get in or pull data out. Each such place is an entry point. It's more than open ports:

• Network: every reachable endpoint, port, and hostname, including forgotten ones.
• Software: your code plus every library, base image, and plugin it pulls in.
• Identity: every account, API key, role, and token that can act on the system.
• Supply chain: the repos, pipelines, and registries that build the system.
• People: anyone who can be tricked into opening a door.

A quick rule: anything an attacker can send input to, or log in to, is attack surface.

4. The asymmetry

At the perimeter, the game favors the attacker:

 AT THE DOOR: the attacker needs ONE way in

   route A ✖   route B ✖   dev-api ✔   admin ✖   CI ✖ ...
                            ▲ one miss is enough for them

 INSIDE: the attacker needs EVERY stage to succeed

   4 Exploit ─▶ 5 Install ─▶ 6 C2 ─▶ 7 Actions
       ✔            ✔         ✖
                              ▲ one catch is enough for you

The attacker also picks the time, skips change control, and uses cheap tools; your controls cost money and slow delivery.

But you know your own system: normal traffic, which pods never call the internet, which roles never create access keys. Every move inside leaves traces in your logs. The aim isn't a perfect perimeter; it's a small surface plus enough visibility to catch the attacker before stage 7.

🧪 Worked example: mapping the attack surface of quote-api

ExampleFin's quote-api (from the story) returns loan quotes. It runs on EKS behind Kong, stores quotes in MongoDB, and reads rate tables from S3.

  customers     partners      anyone
      │ HTTPS      │ API key     │ scans, guesses
      ▼            ▼             ▼
 ┌────────────────────────────────────────┐
 │ Kong   api.example.com                 │ [N1] public routes
 │        dev-api.example.com             │ [N2] forgotten dev
 │        Admin API :8001                 │ [N3] gateway config
 └───────────────────┬────────────────────┘
                     │ mTLS
 ┌───────────────────▼────────────────────┐
 │ EKS cluster                            │ [N4] EKS API endpoint
 │  quote-api pods  /actuator/*           │ [N5] debug endpoints
 │  image: base OS + 140 Maven libraries  │ [S1] dependencies
 │  pod role (IRSA) → S3, KMS             │ [I1] workload identity
 └───────────────────┬────────────────────┘
                     │
          MongoDB · S3 · KMS               [N6] data stores
                     ▲
 AWS console / IAM Identity Center         [I2] human access
 GitHub repo ─▶ Actions ─▶ ECR ─▶ deploy    [C1] build chain
 engineers · support staff · vendors       [P1] people

Now the inventory:

Three quick fixes: lock down dev-api (N2), shrink the pod role (I1), and cut console admins (I2). None needs new tools, just someone asking "what can an attacker touch?"

🛠 Try it (optional, ~5 min)

Pick one service you work on and fill in the table above for it, from memory first:

1. Which hostnames and routes reach it? Any dev, test, or old versions still routed?
2. Which humans and workloads can change it, deploy it, or read its data?
3. What does it depend on that someone else writes?

Then check one answer with access you already have, for example a read-only kubectl get ingress,svc -n <your-dev-namespace> or, if you run Kong, its route list. Anything you can't explain is the gap between what you think is exposed and what is: exactly what attackers find.

🧠 Key takeaways

• The Kill Chain has seven stages; the attacker must win all of them, you need to break one.
• Break it early (cheaper), but add controls at later stages too, because early ones fail.
• Attack surface is anything an attacker can send input to or log in to, people and pipelines included.
• Forgotten things (dev environments, old routes, unused roles) are the most dangerous surface.
• Attackers need one way in; defenders win with a small surface and a visible inside.

📖 Words to know

⏭ Next time

L04: secure design principles, the rules that would have stopped today's ExampleFin story early.

Why "who" matters

"An attacker" isn't one person. A ransomware gang, a foreign intelligence service, and a disgruntled employee will each attack the same company in different ways, for different prizes. Knowing who is likely to come at you tells you which parts of your attack surface to harden first. Security teams call this threat actor profiling.

The four main types

                 MOTIVE              WANTS FROM A FINANCIAL CO.
 ┌────────────┐
 │ Cybercrime │ ─▶ money ........... customer data to sell, account
 └────────────┘                      takeover, fraudulent transfers,
                                     ransom
 ┌────────────┐
 │ Nation-    │ ─▶ strategy, cash .. intelligence, long-term access,
 │ state      │                      disruption, (some) theft
 └────────────┘
 ┌────────────┐
 │ Insider    │ ─▶ money, grudge,... data they can already see,
 └────────────┘    or carelessness   changes they can already make
 ┌────────────┐
 │ Hacktivist │ ─▶ a cause ......... embarrassment: outages, defaced
 └────────────┘                      pages, leaked documents

Cybercriminals are the most common threat to almost any financial firm. They are businesses: they pick targets by expected profit and effort. Their favorites are ransomware, business email compromise (BEC) (tricking staff into paying fake invoices or changing payment details), and account takeover using stolen or reused passwords. They prefer the cheapest entry point, so they love credential stuffing against login APIs and phishing over custom exploits.

Nation-state actors have budgets, patience, and goals beyond profit. Most want espionage and quiet, long-term access. A few are also thieves: the FBI and many security firms attribute the 2016 Bangladesh Bank SWIFT theft (L01) and the February 2025 theft of about $1.5 billion in crypto from the exchange Bybit to North Korean groups. Others aim at disruption: in 2016, the US Justice Department charged seven Iranians over a 2011–2013 DDoS campaign against dozens of US financial institutions.

Insiders are employees, contractors, or vendors who already have legitimate access. That's what makes them hard: they skip reconnaissance, delivery, and exploitation entirely. Some are malicious; in May 2025, Coinbase disclosed that criminals had bribed overseas customer-support contractors to copy customer data, then demanded a $20 million ransom (the company refused). Many more are simply careless: the engineer who copies prod data to a laptop, or pastes a key into a public repo.

Hacktivists attack for a cause and want visibility, not profit. In 2010, Anonymous's "Operation Payback" knocked Visa's and MasterCard's websites offline after they stopped processing donations to WikiLeaks. Their usual tools (DDoS, defacement, leaks) mean availability and reputation are what's at stake.

What each one means for a service like quote-api

A useful habit: when you design or review a feature, ask "which of these four would want to abuse this, and how?" A bulk-export endpoint excites criminals and insiders. A public status page mostly interests hacktivists.

🛠 Try it (~3 min)

For one service you work on, pick the two actor types you think are most likely to target it. For each, write the entry point they'd try first, and the one control that would stop them. If both answers point at the same weak spot, that's your top priority.

🧠 Extra takeaways

• Different attackers want different things: money, intelligence, revenge, or attention.
• Cybercrime is the most likely threat; nation-states are the most capable; insiders skip most of the kill chain.
• Match your defenses to the likely attacker, not to a generic "hacker."

Shrinking beats guarding

Every entry point needs authentication, patching, logging, and someone who remembers it exists. The cheapest way to protect an entry point is to not have it. Attack surface reduction comes down to four moves, in order of preference:

 1 REMOVE ....... delete it     unused route, old API version,
                                stale DNS record, idle IAM role
 2 RESTRICT ..... fewer callers dev env behind VPN, admin API on
                                private network, IP allow-lists
 3 REDUCE ....... less power    one bucket instead of all of S3,
                                read-only DB user, short tokens
 4 MONITOR ...... watch the     alerts on what's left, so misuse
                  rest          is seen early

Common wins in a Kong + EKS + AWS stack

Network.

• Retire old API versions. If /v1/ and /v2/ both exist and /v1/ gets 30 calls a month, find those callers and switch it off.
• Don't route non-prod through public hostnames. Put dev- and qa- gateways behind the VPN or an IP allow-list.
• Keep the Kong Admin API off any public network. Anyone who can reach it can reconfigure every route.
• Restrict the EKS cluster's public API endpoint to known address ranges, or make it private. (By default, EKS creates the endpoint with public access enabled.)
• Delete DNS records for things that no longer exist. A record pointing at a deleted cloud resource can be taken over (subdomain takeover, L08).

Software.

• Drop unused dependencies, and use minimal or distroless base images: no shell, no package manager, far fewer CVEs to patch (L49).
• Turn off debug features in prod: Spring Actuator endpoints beyond health, Swagger UIs, verbose error pages.

Identity.

• Remove access that nobody used in 90 days. AWS IAM Access Analyzer and "last accessed" data show which permissions a role actually uses.
• Prefer short-lived credentials (IAM Identity Center sessions, IRSA) over long-lived access keys.

🧪 Worked example: a before-and-after review

A team runs the review from the main lesson on quote-api. Before and after one sprint:

Now replay the Kill Chain story from the main lesson against the "after" column. Delivery fails: there's no public dev endpoint. Even if another entry point were exploited, the pod's role can no longer read the bucket of copied prod data. Two breaks in one chain, for a sprint's work.

Keeping it small

Attack surface grows back. New features add routes; experiments leave roles behind. Two habits keep it in check:

• Make the inventory a living document. Generate the route list from Kong config (for example, declarative config managed with decK in git) instead of writing it by hand, and review it each quarter.
• Add an attack surface question to design reviews: "What new entry points does this add, who can reach them, and when will we remove them?" Threat modeling (L05) makes this systematic.

🛠 Try it (~3 min)

Certificate transparency logs (L11) are public, and attackers use them for reconnaissance. Visit https://crt.sh/?q=example.com to see what anyone can learn about a domain's hostnames. Then, for a domain your team owns, ask: do any hostnames show up that you didn't know about, or that should no longer exist?

🧠 Extra takeaways

• The cheapest control is removing the entry point entirely.
• Work in order: remove, restrict, reduce, then monitor what's left.
• Non-prod environments, debug endpoints, old API versions, and unused roles are the usual easy wins.
• Attack surface grows back, so generate the inventory from config and review it regularly.