Exploit Chains and Small Weaknesses

By the end of this lesson, you will be able to...

• Trace a bounded attack path as a sequence of conditions, decisions, and outcomes rather than as a list of findings.

• Mark the gates, evidence, uncertainty, and alternative branches that make a proposed chain credible or weak.

• Identify the one condition whose removal would break a path without claiming that every small weakness forms a compromise.

Idea in one sentence: A chain is useful when every link has a supported starting state and the links together explain one unwanted outcome.

Core Insight

Northstar lets document owners share a company link. In the previous lesson, the team wrote a credible abuse case: Ari, a contractor, can read a legitimate support ticket containing a link to a confidential roadmap. If Northstar authorizes any company account that presents the link, Ari may receive a document outside the owner's intended audience.

The easy reaction is to call this one severe flaw. The opposite reaction is to list three smaller issues: “ticket visibility,” “portable link,” and “broad authorization.” Both reactions hide the important question:

Which conditions must all be true, in which order, for the unwanted read to occur?

An exploit chain is a model of that path. In plain English, it is a connected explanation of how an actor moves from a stated starting position to an unwanted outcome. It is not a set of alarming nouns placed in a row. It is not proof that the outcome happened. It is not a recipe for trying the path on a real system.

The pressure is practical. A team has limited time. If it treats every minor weakness as a separate emergency, it cannot see the shared condition that would break several concerns at once. If it joins every concern into a dramatic “full compromise,” it will spend effort on paths that depend on imaginary access or unsupported steps.

The Small Situation: A Link Is Not Yet a Chain

Keep the fictional system small. These are given facts for this lesson:

• A roadmap owner creates a Northstar company link.
• A product-support ticket contains that link to diagnose a display problem.
• Ari has a normal company account and legitimate read access to the ticket.
• Northstar checks whether the requester has a company account and possesses the link; it does not compare the requester with an intended-reader list.
• Northstar records the account identifier and document identifier when it returns a document.

The product promise remains: only intended readers should view the confidential roadmap.

One initial model says, “The ticket is the weakness.” That is tempting because the ticket makes the link visible. It works as a local observation: removing the link from the ticket would remove this particular opportunity.

But it is incomplete. Ticket visibility alone does not return a document. Ari still needs a valid company identity; the link must still be usable; and Northstar must make an authorization decision that accepts that identity. The visible ticket is a precondition, not the whole mechanism.

The opposite initial model says, “Any internal person can read every document.” That is also too broad. The scenario does not say that Ari can discover arbitrary links, alter policy, or see documents shared through a different rule. A chain must preserve those limits.

The Moving Parts: States, Gates, and Evidence

The useful model separates three kinds of things.

A chain is mostly a series of gates. A state lets the actor attempt the next transition. A gate either permits the transition or stops it. Evidence tells the reviewers whether a gate is a system fact, an assumption, or an open question.

This distinction fixes a common mistake. “Ari has a company account” is not an action. It is starting state. “Northstar receives a request from that account with the link” is a transition. “The authorization rule accepts the request” is a gate. “A log records the document response” is possible evidence of the result, not evidence that Ari intended misuse.

Technical name: a precondition is a fact or assumption that must hold before a step can matter. NIST calls broader conditions that change the likelihood or consequences of threat events predisposing conditions. The lesson uses the narrower word precondition because it keeps each link easy to inspect.

The Mechanism Step by Step

Start from Ari's bounded position. The following is a teaching trace, not observed production data and not a test plan.

Starting state
  Ari has a company account and can read the support ticket.

Gate 1: link availability
  The ticket contains a currently usable Northstar link.

Transition
  Ari can present that link while signed in with the ordinary account.

Gate 2: authorization decision
  Northstar accepts “company account + link” as sufficient.

Resulting state
  Northstar returns the roadmap to an account outside the owner's intended audience.

Observable result
  A document-access event could identify the account and document, if logging is retained and reviewed.

Every line has a job. The starting state keeps Ari bounded. Gate 1 names the workflow condition. The transition is deliberately ordinary: presenting a link while signed in. Gate 2 names the decision that conflicts with the product promise. The final event is a potential signal, not a claim that a particular person has acted.

Ask a useful question at each gate. Could Ari read the ticket? Check the ticket audience. Was the link still usable? Check the feature's sharing state. Would the service authorize Ari? Inspect the policy or use an authorized, non-production test account if the team decides verification is necessary. Could the team later distinguish this event from intended use? Inspect the event fields and retention policy.

The path fails as soon as a required gate is false. If the ticket audience does not include Ari, the path ends before the link is available. If Northstar compares an account with an explicit recipient list, the path ends at authorization. That is why a chain should not be summarized as “three issues equal compromise.” The relationship is conditional, not arithmetic.

A Worked Chain Graph

Represent the same reasoning as a small graph. Boxes are states; arrows are transitions; the text on an arrow is the gate that must hold.

[Ari can read ticket]
          |
          | ticket contains usable link
          v
[Ari knows a document link]
          |
          | ordinary company account is accepted
          v
[Northstar returns roadmap]
          |
          | response conflicts with owner-specific promise
          v
[Unintended reader can view document]

Now add a compact evidence ledger:

This table prevents a quiet leap from “the route exists” to “the misuse happened” or “the team will certainly detect it.” It also shows what to repair in the model before prioritizing the path.

So far, the stronger model is: a meaningful chain is an AND of supported gates. One broken gate breaks this path, though it may not break every possible path to the same asset.

Where a Plausible Story Stops

Consider a second story: an unauthenticated outsider somehow finds the link, then reads the roadmap. It may sound more alarming because the actor is outside the company. But the current model says an account is required and gives no route by which the outsider receives one. The story has no supported starting state.

Do not repair that story by silently granting a stolen account, a broken login, or an unknown bypass. Each addition would be a new branch with its own actor, evidence, and gate. It might become worth modeling if new facts arrive. Until then, call it an open question, not a chain.

Likewise, do not combine every Northstar concern just because they involve links. A forwarded-link case might involve an intended reader rather than Ari. It may share the authorization gate but have a different starting state, owner, and decision. The two paths can appear in the same graph as branches, but they should not be merged until their common and different gates are visible.

This is the boundary between disciplined chain thinking and fear-driven storytelling. A chain earns attention through continuity: each result must supply the next starting state, and each important gate needs evidence or an explicit uncertainty.

Cost, Limits, and Signals

Chain thinking improves prioritization. It lets the team ask which gate is both credible and removable. In Northstar, recipient-specific authorization could cut the illustrated path at the decision gate even if a ticket still exposes a link. Narrower ticket access could cut it earlier. The trade-off depends on the product's collaboration needs, support workflow, and the kinds of documents the service handles.

This buys focus, but it costs review effort. Someone must trace permissions, feature behavior, and ownership across boundaries. A detailed graph can also create false precision if every arrow is drawn with the same confidence. Marking unknowns is not a weakness in the analysis; it is how reviewers avoid treating a narrative as measured likelihood.

The method does not assign a probability, prove business impact, choose a complete control set, or replace incident investigation. Later lessons will map credible behavior to prevention, detection, response, and recovery. This lesson stops at the defensive question: which gate would most reliably interrupt the path we can actually support?

Signals reveal the boundary. If a chain diagram needs “and then they somehow get access,” it is incomplete. If a graph has many arrows but no evidence fields, it is a brainstorming artifact, not a prioritization tool. If removing one gate appears to stop every path, test whether another branch reaches the same outcome before treating the control as sufficient.

Trace It Yourself

Check: The team confirms that Ari can read the ticket and that the ticket has a valid link. It then learns that Northstar checks an explicit recipient list, not merely company membership. What happens to the illustrated chain?

Think first, then reveal.

Answer: It stops at the authorization gate. The ticket and account still create an attempted path, but they no longer lead to the unwanted document response. Record the revised rule as evidence. Do not keep the old outcome merely because the earlier links remain true.

Check: A reviewer says, “Ari could steal an administrator session and turn off logging, so the chain is undetectable.” What is missing?

Think first, then reveal.

Answer: The statement introduces new starting access, capabilities, and transitions without evidence. It is a separate hypothetical chain, not a continuation of Ari's bounded profile. The current path should keep its stated constraints.

Practice: Build a Small Evidence-Backed Chain

A fictional expense tool lets an employee attach a receipt through a company link. A finance-help ticket copies the link. Kai, a finance contractor, can read that ticket and has a normal company account. The stated sharing rule is “any company account with the link may view the receipt.” The product promise is: only the employee and assigned approver may view the receipt. The system records account and receipt identifiers for each successful view.

Draw or write a five-part chain from Kai's starting state to the unwanted view. For each part, label it state, gate, or evidence. Then name one condition which, if changed, would break this particular path. Do not propose an exploit or assume new privileges.

A good answer should mention:

• Kai's legitimate ticket access and company account as the bounded starting state;
• a usable link in the ticket as the next gate or condition;
• the company-link authorization rule as the decision gate;
• the receipt view as the outcome that conflicts with the promise;
• the event record as possible evidence of a successful view, not proof of intent;
• one specific interrupting condition, such as a recipient-specific rule or a narrower ticket audience;
• any unknown fact as an open question instead of an invented link.

Resources

• [ARTICLE] NIST SP 800-30 Rev. 1 — Focus: distinguish threat sources, vulnerabilities, predisposing conditions, likelihood, and impact when reasoning about a path.
• [ARTICLE] OWASP Threat Modeling Cheat Sheet — Focus: connect the system model, identified concerns, and responses rather than treating a diagram as a finished analysis.
• [FRAMEWORK] MITRE ATT&CK: Get Started — Focus: use its vocabulary for adversary behavior without assuming every tactic or technique forms one ordered intrusion.
• [ARTICLE] MITRE ATT&CK FAQ: ATT&CK and the Cyber Kill Chain — Focus: note that ATT&CK tactics are not an ordered checklist that every intrusion follows.

Key Takeaways

• A chain connects a bounded starting state to one unwanted outcome through supported gates; a list of findings is not enough.
• Separate states, transitions, gates, and evidence so a reviewer can see exactly where the path is supported or uncertain.
• The path breaks when a required gate is false; do not treat several small issues as automatic compromise.
• A dramatic step with no starting access or evidence is an open question or a separate branch, not a valid continuation.
• Use the graph to find a defensible interruption point, then test whether other branches still reach the same outcome.