4. Structured Analysis of Adversary Behavior

Behavior Models and Competing Hypotheses

Organize adversary activity with behavior-centered models and compare alternative explanations against evidence to reduce premature conclusions.

In this lesson, you will learn to:

  • Apply a behavior-centered model and a competing-hypotheses approach to compare explanations of observed activity, identify discriminating evidence, and record intelligence gaps.

Behavior Models and Competing Hypotheses

Model adversary behavior without forcing the evidence

Behavior models give analysts a shared structure for describing what an adversary did, how actions relate, and where defenders may observe or interrupt the activity. They are analytical aids—not substitutes for evidence and not scripts that every intrusion must follow.

A useful behavior model should help answer four questions:

  1. What was observed? Record actions, objects, identities, systems, and relationships.
  2. What objective could the behavior support? Interpret purpose cautiously and preserve alternatives.
  3. What preceded and followed it? Establish sequence, dependencies, and possible paths.
  4. Where can defenders collect evidence or intervene? Connect behavior to telemetry, controls, and decisions.
Model behavior at the right level

Analysts can describe activity at several levels:

Level Example Strength Limitation
Artifact A file hash or domain Precise and easy to search Often changes quickly and may lack context
Action A process reads browser credential stores Explains what occurred May be produced by benign tools too
Technique or method Credentials are collected from local applications Groups related implementations Can hide important implementation details
Sequence Attachment opened, interpreter launched, persistence created, credentials accessed Preserves behavioral relationships Requires aligned and sufficiently complete telemetry
Objective Establish durable access to payment workflows Connects activity to possible intent and impact Usually inferential and vulnerable to overinterpretation

Choose the level that serves the requirement. A detection engineer may need precise event relationships and data sources. An incident commander may need likely intrusion stage, affected scope, and intervention opportunities. A security leader may need recurring pathways and control gaps.

Do not discard lower-level evidence after assigning a higher-level label. Preserve the observations and explain how they support the classification.

Use frameworks as controlled vocabularies

Frameworks and taxonomies can improve consistency by giving analysts common names for behaviors, relationships, and stages. They can support:

  • normalization across incidents and sources;
  • comparison of recurring behavior;
  • mapping to telemetry and defensive controls;
  • identification of evidence gaps;
  • communication across technical teams;
  • prioritization of detection and hunting work.

Their value depends on disciplined use. Before applying a label:

  • verify that the definition matches the observed behavior;
  • retain the evidence that supports the mapping;
  • note ambiguity when more than one label could apply;
  • distinguish direct observation from inferred objective;
  • record framework and version when changes could affect interpretation;
  • avoid mapping merely to make a report appear complete.

A behavior framework is a map, not the territory. An intrusion may skip expected stages, repeat actions, use legitimate tools, delegate work across actors, or remain only partly visible. Blank spaces may reflect missing telemetry rather than absent behavior.

Build a behavior record

For each meaningful behavior, capture:

Field Purpose
Behavior statement Describes the action in plain language before applying labels
Actor or initiating identity Records the observed account, process, host, or unknown initiator
Action and object States what acted on what
Target and environment Identifies affected assets, users, services, or business processes
Time and sequence Preserves event order, duration, and clock limitations
Evidence references Links to the underlying observations and provenance
Model mapping Applies a framework label with rationale and version
Analytic status Marks observed, inferred, reported, hypothesized, or contradicted
Alternative explanation Records plausible benign, administrative, or different malicious interpretations
Visibility Identifies required data sources and known coverage gaps
Defensive opportunity Notes where prevention, detection, containment, or recovery may be possible
Confidence and change conditions Explains current support and what would revise the mapping

Use behavior statements that can be inspected. “The adversary used persistence” is too abstract by itself. “A newly created scheduled task launched a script from a user-writable directory at sign-in” states what was observed; the analyst can then explain why it is mapped to a persistence behavior.

Separate observed behavior from inferred intent

Technical actions can support several objectives. Credential access may enable lateral movement, fraud, data access, persistence, or reconnaissance. Encryption may indicate extortion, sabotage, testing, or legitimate administration depending on context.

Use an explicit ladder:

  • Observed: A process accessed browser credential databases.
  • Interpreted behavior: The process attempted to collect locally stored authentication material.
  • Possible objective: The material could support access to additional accounts or services.
  • Higher-level judgment: In combination with subsequent sign-ins, the activity was likely intended to reach payment systems.

Each step adds inference. State the evidence and confidence appropriate to that step instead of presenting the highest-level interpretation as a directly observed fact.

Model relationships, not just lists

A list of techniques can summarize activity but may lose the sequence that makes it intelligible. Relationships often provide stronger evidence:

  • which message reached which user;
  • which user action preceded which process;
  • which process created which file or task;
  • which identity authenticated to which service;
  • which system contacted which destination;
  • which action enabled the next one;
  • which control failed, alerted, or interrupted the path.

For Northbridge, compare:

Flat list: phishing attachment, command interpreter, scheduled task, credential access, remote sign-in.

Behavior path: A finance user opened an archive attachment. The extracted script launched an interpreter, created a scheduled task under the user’s identity, accessed browser credential stores, and was followed by a remote sign-in to a payment-support service from an unusual device.

The path reveals dependencies and intervention points. Email controls could prevent delivery; endpoint telemetry could identify the process chain; task creation could trigger investigation; identity controls could constrain the later sign-in.

Treat missing stages carefully

Do not infer every stage between two observations. If an external sign-in follows suspected credential access, the relationship may be plausible but not confirmed. Record the gap:

Credential collection and the later sign-in may be related, but available evidence does not establish how the credentials were obtained or whether the same operator controlled both actions.

Likewise, the absence of a modeled stage does not prove it did not occur. Ask whether the organization had the necessary visibility, whether the behavior would create a detectable signal, and whether retention covered the period.

Use statuses such as:

  • observed: directly supported by collected evidence;
  • reported: asserted by another source with provenance;
  • inferred: reasoned from evidence but not directly observed;
  • hypothesized: proposed for testing;
  • not observed: sought but not found in adequate visibility;
  • unknown: evidence is insufficient to determine status;
  • contradicted: credible evidence weighs against the behavior.

These labels prevent “unknown” from becoming “absent” and “reported” from becoming “confirmed.”

Avoid actor-label dependence

Behavior modeling should remain useful even if attribution changes. Actor names can help organize historical reporting, but they also introduce problems:

  • different sources use different names for overlapping or distinct clusters;
  • a cluster may contain infrastructure or behaviors shared by several operators;
  • an adversary can copy another’s tools or methods;
  • labels may merge or split as evidence changes;
  • familiarity with a named actor can anchor interpretation.

Describe the behavior first. Add attribution only when it serves the requirement and the evidence supports it. A detection rule should usually identify observable behavior rather than depend on a threat-group name.

Worked example: model the Northbridge sequence

Northbridge has the following evidence:

  • three finance users received similarly constructed archive attachments;
  • two hosts launched the same interpreter command from an extracted directory;
  • one host created a scheduled task that referenced the script;
  • browser credential stores were accessed on that host;
  • a payment-support account later authenticated from a new device;
  • telemetry is incomplete on the third host.

A disciplined model records:

Behavior Status Evidence and limitation Defensive opportunity
Delivery through archive attachment Observed on three messages Email records preserve sender, recipient, attachment, and time Attachment controls and targeted-user warning
User execution Observed on two hosts; unknown on one Process ancestry confirms two executions; third host lacks endpoint data Application controls and process-chain alerting
Scheduled-task persistence Observed on one host Task record and script path are preserved Task-creation monitoring and containment
Browser credential access Observed; purpose inferred File access is recorded, but successful extraction is unconfirmed Credential-store protections and memory collection
Use of obtained credentials Hypothesized New-device sign-in followed the activity; direct linkage is absent Step-up authentication, session review, account reset
Coordinated campaign Analytic judgment Similar delivery and execution support a common cause; scope remains incomplete Widened search across finance and related identities

The model exposes uncertainty rather than filling gaps with a familiar intrusion narrative.

Connect models to collection and defense

A behavior model should produce practical next steps:

  • identify telemetry needed to confirm or refute inferred behaviors;
  • reveal choke points shared across several plausible paths;
  • distinguish controls that prevent, detect, contain, or recover;
  • generate hunt hypotheses with explicit expected observations;
  • expose where the environment lacks visibility;
  • help consumers prioritize durable capability over one-off artifact blocking.

For example, if several intrusion paths require unusual access to browser credential stores, defenders can improve telemetry and restrictions around that behavior even if domains and file hashes vary.

Key takeaways
  • Behavior models organize evidence and relationships; they do not manufacture missing evidence.
  • Preserve plain-language observations beneath framework labels.
  • Choose artifact, action, technique, sequence, or objective detail according to the decision.
  • Separate directly observed behavior from inferred purpose and higher-level intent.
  • Model sequences and dependencies to reveal collection gaps and defensive opportunities.
  • Mark unknown, reported, inferred, and contradicted behavior explicitly.
  • Analyze behavior before relying on actor labels.

Analyst habit: For every model label, ask: What exactly did we observe, which part did we infer, and would the assessment remain useful if the actor name disappeared?

Compare competing hypotheses and target decisive gaps

Competing-hypotheses analysis helps analysts compare plausible explanations against the full body of evidence. Its purpose is not to calculate an answer mechanically. It is to reduce premature closure, expose assumptions, identify diagnostic evidence, and direct collection toward gaps that could change the decision.

Use the technique when:

  • several explanations reasonably fit the observations;
  • the consequences of a mistaken judgment are material;
  • an early narrative or actor label is dominating discussion;
  • evidence is incomplete, contradictory, or drawn from sources with different access;
  • the team needs to decide which information gap deserves priority;
  • reviewers need a transparent record of why one explanation was favored.

A lightweight comparison may be sufficient during an incident. A consequential strategic assessment may require independent hypothesis generation, a documented matrix, peer review, and formal dissent. Match the rigor to the decision and the cost of error or delay.

Define hypotheses that can compete

A hypothesis is a testable explanation of the relevant observations. Good hypotheses should be:

  • mutually distinguishable enough to compare;
  • plausible given current knowledge;
  • stated at a similar level of scope and detail;
  • capable of being weakened or strengthened by obtainable evidence;
  • collectively broad enough to include important benign, malicious, and mixed explanations.

For the Northbridge activity, the team might define:

  • H1 — Coordinated intrusion: A common malicious operation delivered the attachments and produced the related host and identity activity.
  • H2 — Authorized activity: A legitimate deployment or administrative workflow produced the technical events, while the messages were unrelated or expected.
  • H3 — Telemetry or processing error: Duplicated, misaligned, or incorrectly parsed records created the appearance of coordinated activity.
  • H4 — Mixed events: Some hosts experienced malicious activity, while other observations arose from benign or unrelated causes.

Avoid hypotheses such as “H1 is a sophisticated state actor” versus “H2 is nothing.” The first combines activity, capability, and attribution; the second is undefined. Begin with explanations of the observed behavior. Attribution can be analyzed separately if the requirement calls for it.

Inventory evidence before scoring it

List material evidence without sorting it into the preferred story. Include:

  • supporting observations;
  • contradictory information;
  • reported claims not yet independently verified;
  • relevant negative evidence;
  • collection and visibility gaps;
  • provenance and source limitations;
  • important assumptions;
  • timing and sequence uncertainty.

Break compound evidence into testable statements. “The hosts behaved identically” may conceal several claims about process ancestry, command lines, destinations, and timing. Separate them because individual elements may have different provenance or diagnostic value.

For example:

  • three finance users received similarly constructed archive attachments;
  • two hosts launched the same interpreter command from extracted directories;
  • one host created a scheduled task referencing the extracted script;
  • raw event identifiers differ across hosts;
  • no approved change record has been found;
  • one administration tool can produce part of the process pattern;
  • identity telemetry records a later sign-in from a new device;
  • endpoint coverage is missing on the third host;
  • payload contents have not been recovered.

Do not let evidence quantity substitute for independence. Ten fields generated from one sensor failure may represent one underlying evidentiary weakness.

Compare consistency, not confirmation alone

For each evidence item, ask how expected it would be if each hypothesis were true. A simple scale is often enough:

  • Strongly consistent
  • Consistent
  • Neutral or not diagnostic
  • Inconsistent
  • Strongly inconsistent
  • Unknown because evidence or visibility is inadequate

A compact matrix might look like this:

Evidence H1: Coordinated intrusion H2: Authorized activity H3: Telemetry error H4: Mixed events
Similar archive messages reached three finance users Strongly consistent Inconsistent unless planned Neutral if email records are genuine Consistent
Same unusual command on two hosts Strongly consistent Consistent if deployment used it Consistent if records were duplicated Consistent
Raw identifiers confirm distinct host events Consistent Consistent Strongly inconsistent with simple duplication Consistent
No approved change record found Consistent Inconsistent, but records may be incomplete Neutral Consistent
Scheduled task references extracted script Strongly consistent Possible but unusual Inconsistent if confirmed in raw host data Consistent
New-device sign-in follows credential-store access Consistent but linkage unconfirmed Inconsistent unless separately explained Possible if timestamps are wrong Consistent
Third host lacks endpoint coverage Neutral Neutral Neutral Neutral

The matrix draws attention to evidence that discriminates. Missing endpoint coverage is important for scope and confidence, but it does not favor one explanation by itself. Distinct raw identifiers weigh against a simple duplication error. A validated change record matching the complete sequence would strongly favor authorized activity.

Focus on inconsistency and diagnostic value

Analysts often count how many items support each hypothesis. That approach is misleading because many observations are compatible with several explanations. Give greater attention to evidence that is difficult to reconcile with a hypothesis.

Ask:

  • Which item is least expected if this hypothesis is true?
  • Does the inconsistency reflect the hypothesis, bad evidence, or an unstated assumption?
  • Is one item genuinely independent or derived from another?
  • Would removing one weak source collapse the conclusion?
  • Which evidence separates the two leading hypotheses most sharply?

Do not multiply numerical weights unless the scale and method are well defined. A matrix supports disciplined judgment; it does not turn ordinal impressions into statistically valid probabilities.

Identify load-bearing assumptions

After comparing evidence, record assumptions that materially affect the result. Examples include:

  • the message and endpoint clocks are aligned within the required precision;
  • the change-management system contains all authorized deployments;
  • the administration tool cannot explain the complete observed sequence;
  • the later sign-in belongs to the same incident window;
  • raw event identifiers reliably distinguish hosts;
  • missing endpoint data is not systematically hiding benign activity.

Test sensitivity by asking: If this assumption were false, would the leading hypothesis change?

If yes, the assumption is load-bearing and becomes a priority intelligence gap. If no, it may still deserve documentation but should not displace more decisive collection.

Turn gaps into discriminating collection

An intelligence gap is not simply something unknown. A priority gap is missing information that could materially alter likelihood, confidence, scope, implications, or the consumer’s decision.

Rank candidate collection questions by:

  1. Discriminating power: How differently would the possible answers affect the leading hypotheses?
  2. Decision impact: Could the result change what the consumer does?
  3. Feasibility: Can the evidence be obtained lawfully, safely, and in time?
  4. Reliability: Would the candidate source provide a trustworthy answer?
  5. Cost and risk: What operational, privacy, safety, or opportunity costs arise?
  6. Uniqueness: Does another available source already answer the question?

For Northbridge:

Gap Why it matters Collection action Possible effect
Was a matching deployment authorized? Strongly separates H1 from H2 Confirm with software owner and review signed package and change records A complete match would raise H2 substantially; a confirmed absence weakens it
Are the host events genuinely distinct? Tests H3 Inspect preserved raw identifiers and source-system ingestion records Distinct originals weaken simple duplication explanations
What did the extracted script do? Tests malicious versus administrative behavior Recover file, memory, or sandbox evidence under approved procedures Malicious functions strengthen H1; a signed approved package strengthens H2
Is the later sign-in linked to collected credentials? Affects intrusion scope and implications Review session, device, token, and identity sequence A defensible link strengthens H1 and changes containment priorities
What occurred on the third host? Clarifies scope and mixed-event possibility Seek alternate telemetry or conduct targeted examination Similar behavior strengthens common cause; benign evidence may favor H4

“Collect more logs” is not a good task. Specify which source, fields, time window, and expected observation would discriminate among hypotheses.

Beware evidence generated by response actions

Investigation and containment can change the environment. Blocking a domain, resetting an account, detonating a sample, or notifying a user may create new events or cause an operator to change behavior. Record response actions alongside observations so later analysts do not attribute defender-generated effects to the adversary.

For example, a failed sign-in after an account reset may result from an existing legitimate session rather than continued adversary activity. A sudden loss of network contact after blocking does not establish what controlled the destination. Preserve sequence and alternative explanations.

Use independent review and structured dissent

A reviewer should challenge the reasoning, not merely edit prose. Useful review prompts include:

  • Is an important hypothesis missing?
  • Are hypotheses defined at comparable levels?
  • Which evidence items share one source or dependency?
  • Were contradictions represented fairly?
  • Are “unknown” and “not observed” distinguished?
  • Does the leading hypothesis depend on an untested assumption?
  • Which collection task has the greatest discriminating value?
  • Would a different framing of the requirement change the comparison?

Where feasible, ask analysts to record an initial ranking independently before group discussion. This reduces anchoring on the first confident speaker. A red-team or devil’s-advocate role can help, but the role should present evidence-based challenges rather than argue an implausible position for ceremony.

If credible disagreement remains, preserve it. State which evidence or assumption creates the split and what would resolve it.

Move from comparison to assessment

The output should be a judgment, not merely a matrix. Summarize:

  • the leading explanation and likelihood;
  • confidence and its basis;
  • why the strongest alternatives are less consistent;
  • important supporting and contradictory evidence;
  • load-bearing assumptions;
  • material gaps and collection priorities;
  • implications for the consumer;
  • evidence that would change the judgment.

A Northbridge assessment might read:

We assess the events on at least two finance workstations were likely part of a coordinated intrusion attempt, with moderate confidence. Similar targeted delivery, matching process behavior, distinct raw host events, and scheduled-task creation are more consistent with a common malicious cause than with simple telemetry duplication. Authorized activity remains plausible because an approved administration tool can produce part of the sequence, but no matching deployment has been confirmed. The third host and the relationship between credential-store access and the later sign-in remain unresolved. Validation with the software owner and recovery of the extracted script would most strongly change the assessment.

This statement explains why the leading hypothesis is favored without claiming that alternatives have disappeared.

Lightweight workflow for time-sensitive analysis

During a fast-moving incident, use a shortened version:

  1. Define the decision and proposition.
  2. Name at least three plausible explanations, including benign or mixed activity where appropriate.
  3. List the five to ten most material observations and gaps.
  4. Mark which evidence strongly conflicts with each explanation.
  5. Identify one or two load-bearing assumptions.
  6. Select the next collection action with the highest discriminating value.
  7. Deliver the current judgment, confidence, alternatives, and update trigger.

The technique should accelerate useful learning, not delay an urgent decision in pursuit of a perfect matrix.

Common failure modes
  • Hypothesis duplication: Several hypotheses use different words for the same explanation.
  • Unequal specificity: A narrow hypothesis competes against a vague category such as “something benign.”
  • Missing mixed explanation: Analysts assume all observations must share one cause.
  • Evidence counting: Numerous weak or dependent items outweigh one decisive contradiction.
  • Confirmation scoring: The team asks only what supports each hypothesis instead of what is inconsistent.
  • Static analysis: New evidence is added without reevaluating hypotheses or assumptions.
  • Collection without decision value: Analysts pursue interesting gaps that cannot change the consumer’s choice.
  • Matrix certainty: A structured table is mistaken for an objective probability calculation.
  • Forced consensus: Material disagreement is removed from the product.
Key takeaways
  • Competing-hypotheses analysis compares plausible explanations against supporting, contradictory, and missing evidence.
  • Define hypotheses at comparable levels and include benign, malicious, telemetry-error, and mixed explanations when plausible.
  • Diagnostic evidence and inconsistency matter more than raw evidence counts.
  • Trace dependencies so repeated reporting does not masquerade as independent support.
  • Test load-bearing assumptions and direct collection toward gaps that could change the judgment or decision.
  • Preserve material disagreement and state what evidence would resolve it.
  • Finish with a clear assessment, confidence rationale, implications, and change conditions.

Analyst habit: When requesting more information, complete this sentence: If the answer is X, it favors this explanation; if the answer is Y, it favors that explanation; either result could change this decision. If you cannot, the gap may not deserve priority.