Defining and Testing a Campaign Hypothesis

Defining and Testing a Campaign Hypothesis

Define campaign boundaries, compare competing explanations, evaluate temporal, behavioral, infrastructure, targeting, and victim evidence, and document confidence and change conditions.

Define campaign boundaries and competing explanations

A campaign is an analytical grouping of related adversary activity across time, targets, infrastructure, tooling, behavior, or objectives. It is not a fact discovered in one artifact, and it is not synonymous with a named actor. Analysts construct a campaign hypothesis to explain why several observations or incidents may belong together.

A useful campaign hypothesis answers:

• Which activity is proposed for inclusion?
• Which evidence relates the activity?
• Which period, targets, behaviors, and objectives define the boundary?
• Which alternatives could explain the overlap?
• How confident are we that the grouping is useful and valid?
• What decision will the grouping support?
• What evidence would add, remove, split, merge, or close campaign membership?

Start with an operational purpose

Campaign analysis should support a decision such as:

• whether to broaden a hunt across incidents or organizations;
• which recurring behaviors deserve durable detection;
• whether current activity represents continuation, adaptation, or a separate operation;
• which partners need a warning;
• which defensive choke points recur;
• how likely activity is to continue or change;
• whether a strategic risk or capability investment requires attention.

Weak purpose:

Build a profile of the campaign.

Stronger purpose:

Determine whether Project Lantern and two partner incidents belong to one recurring campaign so Northbridge can decide which behavior-centered detections, partner warnings, and infrastructure monitoring should continue beyond the immediate incident.

Define the campaign unit

Different analytical units may be appropriate:

Do not force every technical cluster into a campaign. A shared tool may connect incidents technically without showing coordinated operations or a common objective.

Write inclusion and exclusion rules

Campaign boundaries should be reproducible enough that another analyst can evaluate membership.

For a fictional Lantern Campaign Hypothesis, proposed inclusion criteria might be:

• finance or payment-related personnel receive similarly structured archive messages;
• execution involves a related script family or distinctive process sequence;
• activity accesses browser credential stores or related authentication material;
• infrastructure uses a compatible response path or provisioning pattern;
• events fall within 1 August–30 September;
• at least two independent evidence families support inclusion.

Exclusion rules might be:

• only a generic public administration tool overlaps;
• infrastructure overlap is limited to shared cloud hosting;
• message similarity is common across unrelated spam;
• timing falls outside the assessed period without evidence of continuity;
• protected evidence demonstrates authorized activity;
• the event is derived only from circular reporting.

Criteria are guides, not mechanical truth. Record exceptions and why they were accepted.

Bound the campaign across dimensions

A campaign can be useful while objective and identity remain uncertain.

Generate competing campaign explanations

For Project Lantern and two partner incidents:

• H1 — One coordinated campaign: A common operator or tightly coordinated team conducted related operations.
• H2 — Shared criminal service or tool: Different operators used the same delivery, tooling, or infrastructure provider.
• H3 — Copying or imitation: One operator copied techniques or public reporting from another.
• H4 — Common target environment: Similar behavior reflects constraints of finance systems rather than common operation.
• H5 — Reporting or dataset artifact: Shared sources, vendor definitions, or processing created apparent continuity.
• H6 — Mixed activity: Some incidents form a campaign while others are separate or benign.

The hypothesis set should include common-service and mixed explanations. These often fit cyber evidence better than a simple same-actor versus unrelated binary.

Build a campaign evidence model

Campaign evidence spans several families:

No single family must decide membership, but dependence and transferability should be explicit.

Use diagnostic features

A feature is diagnostic when it is more expected under one campaign explanation than alternatives.

Potentially stronger features:

• an uncommon multi-step behavior sequence;
• protected administrative continuity;
• coordinated replacement of infrastructure after disruption;
• a private configuration or build relationship;
• repeated targeting of a narrowly defined business process;
• a distinctive error and recovery pattern;
• independent observations across victims.

Often weaker features:

• same public tool;
• same broad sector;
• same country or cloud provider;
• same generic framework technique;
• similar filenames;
• shared address on multi-tenant hosting;
• identical wording copied from public reporting.

Diagnostic value depends on the reference environment. “Rare” requires comparison, not intuition.

Preserve campaign uncertainty

Campaign membership can use states:

Assign confidence and rationale to membership, not only the overall campaign.

Avoid circular campaign definitions

A circular definition says an incident belongs because it uses “campaign infrastructure,” while infrastructure is considered part of the campaign because the incident used it.

Break the loop with independent anchors:

• preserved victim telemetry;
• protected provider or account evidence;
• independently observed tooling or behavior;
• event-time infrastructure relationships;
• explicit inclusion criteria defined before evaluating the candidate.

Every campaign edge should trace to evidence beyond the label itself.

Project Lantern campaign framing

Northbridge compares Project Lantern with Partner Incidents P-2 and P-3:

• P-2 uses a related script lineage, similar archive delivery, and the same uncommon service path.
• P-3 shares the broad tool family and finance targeting but uses different delivery, infrastructure, and execution.
• The tool is available to multiple customers.
• P-2 and Project Lantern occur within ten days; P-3 occurred six months earlier.
• Independent telemetry exists for Project Lantern and P-2; most P-3 detail derives from one vendor report.

Initial membership:

• Project Lantern: core
• P-2: probable, moderate confidence
• P-3: candidate, low confidence

The campaign remains identity-neutral. Current evidence supports comparing behavior and defenses, not claiming one named operator.

Campaign hypothesis record

Record:

• campaign identifier and version;
• operational purpose;
• defining proposition;
• time, victim, behavior, infrastructure, tooling, objective, and identity boundaries;
• inclusion and exclusion rules;
• core, probable, possible, candidate, excluded, split, and unknown members;
• evidence and source lineage for each member;
• competing explanations;
• confidence and load-bearing assumptions;
• change, split, merge, and closure conditions;
• intended uses and prohibited overinterpretations;
• owner, review date, and feedback route.

Common boundary failures

• Tool equals campaign: All users of one malware family are grouped together.
• Actor-name inheritance: A vendor label determines membership without shared definitions.
• Sector circularity: Incidents are linked because they target finance, then finance targeting is treated as proof of linkage.
• Timeless continuity: Activity separated by years is grouped without evidence of persistence.
• Shared-service inflation: Common provider infrastructure becomes campaign ownership.
• One-cause assumption: Every candidate is forced into the same campaign.
• Source-coverage bias: Only incidents visible to one vendor define the victim pattern.
• Static membership: New evidence never removes, splits, or reclassifies activity.

Key takeaways

• A campaign is an analytical grouping created for a decision, not a synonym for an actor or tool.
• Define the unit of analysis and write explicit inclusion, exclusion, time, behavior, victim, infrastructure, and objective boundaries.
• Compare one-campaign explanations with shared-service, copying, environmental, reporting-error, and mixed alternatives.
• Favor diagnostic, independent, temporally compatible evidence over common features.
• Use graded membership states and confidence rationales.
• Anchor relationships in evidence to avoid circular definitions.
• Keep the campaign identity-neutral unless stronger evidence and decision need justify attribution.

Analyst habit: Before adding an incident to a campaign, identify one feature that supports inclusion and one plausible explanation that could produce the same feature without common campaign control.

Evaluate campaign evidence and update membership

Campaign analysis becomes useful when membership can be tested, revised, and connected to defensive decisions. Analysts should evaluate each candidate against the campaign hypothesis, document evidence dependencies, and change the grouping when contrary evidence appears.

Create a membership matrix

For every candidate operation or incident, compare the same evidence dimensions:

The matrix reveals which dimensions support continuity and which remain common, missing, or dependent.

Evaluate evidence at the feature level

Avoid broad statements such as “the behavior matches.” Decompose overlap:

• Which exact actions recur?
• Is the order the same?
• Which parameters, paths, configurations, or timing patterns are unusual?
• Which features are defaults or publicly documented?
• Which differences may indicate evolution, customer variation, or unrelated activity?
• Does the source observe the behavior directly or repeat another assessment?

Example:

Project Lantern and P-2 both use an archive-to-interpreter-to-script sequence and an uncommon service path. P-2 does not create the same scheduled task. The difference may reflect adaptation, incomplete visibility, or a separate operator using related tooling.

This is more informative than “same TTPs.”

Trace evidence dependencies

Create a lineage map for material similarities:

Dependent reporting can still add interpretation or distribution, but it should not multiply evidentiary weight.

Compare campaign explanations

Use an inconsistency-oriented matrix:

Current evidence may support one campaign for Lantern and P-2 while keeping P-3 outside or pending. Campaign analysis need not force all candidates into one answer.

Define discriminating collection

Ask which obtainable evidence would change membership:

A gap deserves priority when plausible answers would add, remove, split, or merge membership or change a defensive action.

Score transparently without false precision

Teams may use structured ratings to organize comparison, but the score must not masquerade as probability. A simple approach is:

• strongly supports inclusion;
• supports inclusion;
• neutral or common;
• challenges inclusion;
• strongly challenges inclusion;
• unknown.

Record rationale and dependencies. Do not total ordinal values into a percentage unless a validated method supports that calculation.

An incident with fewer but highly diagnostic, independent matches may deserve stronger membership than one with many common similarities.

Review differences as evidence

Differences can indicate:

• normal campaign evolution;
• environmental adaptation;
• different phases or objectives;
• different customers of a shared service;
• separate operators;
• incomplete visibility;
• analytical error.

For each difference, ask:

• Would the campaign hypothesis predict variation here?
• Did a defensive action make adaptation necessary?
• Is the feature under operator control or environment-determined?
• Does the difference appear systematically across a subset?
• Would splitting the campaign improve prediction or defense?

Do not explain every contradiction as “the adversary evolved.” That makes the hypothesis unfalsifiable.

Split and merge campaigns deliberately

Split when:

• subgroups show consistently different behaviors, objectives, targets, or control evidence;
• common features are explained by a shared tool or provider;
• new evidence contradicts common operational control;
• the combined campaign no longer supports useful prediction or defense.

Merge when:

• independent evidence establishes stronger continuity;
• previously separate infrastructure or tooling is linked through protected control evidence;
• temporal and operational patterns reveal coordinated sequencing;
• the merged grouping improves decision support without erasing meaningful differences.

Record:

• prior identifiers and versions;
• reason for split or merge;
• affected members;
• judgments, detections, warnings, or partner releases that require review;
• handling and correction needs.

Maintain membership states over time

Campaign membership is versioned:

Preserve why the judgment changed. Consumers may have created controls or warnings based on earlier membership.

Connect membership to operational use

Campaign membership should affect a defined action:

Do not convert candidate infrastructure into blocking merely because it appears near a campaign graph.

Assess campaign confidence by proposition

Keep separate judgments:

• Lantern and P-2 share a tool lineage: likely, high confidence.
• Lantern and P-2 belong to related operations: likely, moderate confidence.
• One operator controlled both: roughly even chance, low confidence.
• P-3 belongs to the campaign: unlikely after direct review, moderate confidence.
• Similar finance targeting reflects a deliberate campaign objective: possible, low confidence because source coverage is biased.

This prevents strong technical overlap from inflating identity or objective claims.

Review warning indicators

Campaign analysis can generate warning indicators such as:

• the distinctive delivery-and-execution sequence;
• new infrastructure with a validated uncommon service pattern;
• targeting of the same narrowly defined business role;
• resource replacement after a known disruption;
• reappearance of a protected configuration or deployment pattern;
• combinations of behaviors that distinguish the campaign from ordinary administration.

Each indicator should specify:

• campaign hypothesis supported;
• expected observation;
• source and coverage requirements;
• benign alternatives;
• threshold for escalation;
• intended use;
• expiration and review owner.

Conduct a campaign review

At each review:

1. Reconfirm the decision the campaign supports.
2. Review defining boundaries and source coverage.
3. Reassess core and non-core members.
4. Trace new evidence and dependencies.
5. Test competing explanations and contradictions.
6. Review differences for evolution, environmental effects, or split signals.
7. Update likelihood, confidence, and change conditions.
8. Revise warning indicators, hunts, detections, and partner releases.
9. Expire stale infrastructure and unsupported relationships.
10. Record version changes and affected consumers.

Project Lantern membership decision

After direct evidence arrives for P-3, analysts determine that:

• P-3 used the same commercial tool family but a different delivery path, configuration structure, infrastructure model, and victim-selection process.
• The original claimed overlap came from one vendor’s broad actor definition repeated by several publications.
• No protected account, service path, or behavioral sequence connects P-3 to Lantern or P-2.

P-3 is excluded from the Lantern Campaign. The team retains the tool-family relationship for enrichment but removes P-3 infrastructure from campaign monitoring and reviews any controls derived from the earlier candidate status.

Lantern and P-2 remain related with moderate confidence. Common operator control remains unresolved.

Membership review checklist

• Every candidate is compared across time, victims, delivery, behavior, tooling, infrastructure, objective, and source lineage.
• Evidence features are decomposed rather than summarized as generic similarity.
• Dependencies and repeated reporting are visible.
• One-campaign, shared-service, copying, reporting-artifact, and mixed explanations are compared.
• Differences are tested rather than automatically explained as evolution.
• Collection targets evidence capable of changing membership or action.
• Membership states and confidence are versioned.
• Split and merge criteria are explicit.
• Operational use matches membership strength.
• Changes trigger review of detections, warnings, sharing, and controls.

Key takeaways

• Campaign membership is a revisable analytic judgment, not a permanent label.
• Compare candidates consistently and decompose exact similarities and differences.
• Trace source dependencies so publication volume does not become false corroboration.
• Target gaps whose answers can add, remove, split, or merge members.
• Treat contradictions as possible split signals rather than explaining every difference as adaptation.
• Assign confidence to technical overlap, operational relationship, identity, and objective separately.
• Connect membership states to bounded operational uses and review downstream controls when membership changes.

Analyst habit: For every campaign member, write the strongest reason to include it and the strongest reason to exclude it. If neither is specific, the membership judgment is not ready.