Analyzing Adversary Infrastructure in Time and Context

Analyzing Adversary Infrastructure in Time and Context

Develop infrastructure hypotheses, trace evidentiary lineage, distinguish shared and dedicated resources, evaluate temporal overlap, and select safe operational uses for infrastructure findings.

Treat infrastructure as time-bounded relational evidence

Infrastructure analysis examines how domains, addresses, certificates, autonomous systems, hosting providers, name servers, registrars, services, accounts, and observed behaviors relate during a defined period. Its purpose is not to build the largest possible graph. It is to test propositions that support an operational decision.

A domain or address is not a permanent identity. Infrastructure can be shared, reassigned, compromised, sinkholed, parked, proxied, or used for both benign and malicious purposes. Record what was observed, when it was true, which behavior gave it meaning, and what action the evidence can safely support.

Start with a proposition

Weak question:

What else is connected to this IP address?

Stronger question:

During the Project Lantern event window, did sync-example.invalid, its resolved addresses, and related certificates form infrastructure used to deliver or control the activity observed on Hosts A and B, and which relationships are sufficiently supported for hunting, monitoring, or containment?

The stronger question defines:

• the assessed period;
• the infrastructure elements;
• the behavior under examination;
• the relationship being tested;
• the intended operational uses.

Separate observation from interpretation

Use an infrastructure record that distinguishes layers:

Do not store the conclusion “malicious IP” as though it were the original observation.

Make time part of every relationship

Infrastructure relationships are temporal. Record:

• first and last observed;
• lookup or collection time;
• event-time relationship;
• source coverage and historical depth;
• registration, issuance, activation, or reassignment time where relevant;
• last validation time;
• operational validity and expiration;
• review or change trigger.

A current lookup cannot prove historical state. If sync-example.invalid resolves to a different address today, that does not invalidate a preserved resolution observed during the incident. Conversely, a historical association does not justify current blocking without revalidation.

Use interval language:

Source P observed the domain resolving to 203.0.113.24 between 3 and 12 August. Northbridge directly observed the resolution at 09:13 UTC on 12 August. The relationship outside those observations is unknown.

Avoid:

The domain has always used 203.0.113.24.

Identify infrastructure entity types

No entity type proves common control on its own.

Model relationship types precisely

Avoid the vague label “associated with.” Use relationships such as:

• resolved-to;
• hosted-on;
• served-certificate;
• registered-through;
• delegated-to-name-server;
• redirected-to;
• contacted-by-process;
• delivered-file;
• shared-account-or-tenant;
• co-observed-in-incident;
• reused-configuration;
• mentioned-by-source;
• replaced-by;
• sinkholed-at;
• possibly-controlled-with.

For every edge, record source, time, direction, status, confidence, and limitation.

Example:

Evaluate shared infrastructure risk

Before treating a relationship as specific, ask:

• Is the resource dedicated or multi-tenant?
• How many unrelated services share it?
• Does the observed port, protocol, hostname, path, certificate, or account narrow the relationship?
• Was the resource compromised or legitimately rented?
• Could a content-delivery network, reverse proxy, VPN, relay, or cloud platform obscure the actual endpoint?
• Does the source observe client-side resolution, server-side routing, or only public metadata?
• Would blocking affect unrelated users or services?

A shared cloud address may be useful for enrichment but unsafe for preventive blocking. A precise hostname and URL path used by the observed process may provide stronger operational specificity.

Trace source lineage and independence

Infrastructure datasets often copy or license one another. Five identical observations may derive from one sensor.

For each source, record:

• direct observation or copied reporting;
• sensor or customer coverage;
• collection method and frequency;
• historical retention;
• timestamp semantics;
• passive, active, public, partner, or internal origin;
• transformations and deduplication;
• confidence or validation method;
• dependencies on other providers.

Corroboration is stronger when internal telemetry, an independent passive source, and a directly observed certificate agree during compatible periods. Repetition across blogs citing one report is not independent evidence.

Distinguish infrastructure roles

The same infrastructure can serve different roles:

• delivery;
• redirect or traffic distribution;
• command and control;
• credential collection;
• staging or storage;
• exfiltration;
• scanning;
• administration;
• tracking;
• legitimate dependency;
• defensive sinkhole or research system.

Assign a role only when evidence supports it.

Weak:

The address is command-and-control infrastructure.

Stronger:

Hosts A and B contacted the domain after script execution, but available traffic metadata does not reveal content or control behavior. We assess the infrastructure was likely operationally related; its precise role remains unknown.

Use behavioral context to raise specificity

Infrastructure becomes more meaningful when combined with behavior:

• Which process initiated the connection?
• What occurred before and after it?
• Was the destination supplied by a message, script, configuration, redirect, or lookup?
• Which protocol, hostname, certificate, path, or payload was used?
• Did the connection recur according to a pattern?
• Was the activity expected for the host and user?
• Did other affected entities show the same relationship?
• Did the destination respond, and what evidence describes the exchange?

A domain match from a browser may have different evidentiary weight from the same domain contacted by an extracted script after targeted delivery.

Account for adversary and environmental change

Infrastructure changes because of:

• deliberate rotation;
• defender blocking or takedown;
• provider suspension;
• resource expiration;
• reassignment;
• automation;
• victim remediation;
• operator error;
• shared-service behavior;
• sinkholing or research intervention.

Do not assume every change reflects adversary adaptation. Record the timing of defender and provider actions before explaining the change.

Project Lantern infrastructure record

At the 13:20 information cutoff:

• Hosts A and B directly resolved and contacted sync-example.invalid after related script execution.
• Internal DNS and endpoint records establish the client-to-domain relationship.
• An independent historical source observed the domain on 203.0.113.24 during 3–12 August.
• The address hosts several unrelated services, so address-level blocking creates collateral risk.
• A certificate observed on the domain overlaps with another suspicious hostname, but automated issuance and incomplete historical coverage limit the relationship.
• The domain changed resolution after the defender block and provider notification; the change does not independently prove evasion.
• Current evidence supports process-context hunting and hostname monitoring. It does not support treating every service on the address as malicious.

Infrastructure evidence checklist

• The proposition, decision, and intended operational use are explicit.
• Every entity and relationship has source, direction, period, status, and limitation.
• Event-time observations are distinguished from current enrichment.
• Original records and transformations are traceable.
• Shared hosting, proxies, cloud services, and reassignment risks are evaluated.
• Source independence and dataset lineage are understood.
• Behavioral context supports infrastructure interpretation.
• Infrastructure role is assessed separately from mere contact.
• Defender, provider, and environmental changes are included.
• Validity, expiration, revalidation, and safe-use conditions are recorded.

Key takeaways

• Infrastructure is volatile, relational, and time-bounded evidence—not a permanent malicious identity.
• Start with a proposition connected to a decision and an intended use.
• Preserve observation, enrichment, judgment, and action as separate layers.
• Use precise relationship types with direction, time, provenance, confidence, and limitations.
• Shared services and copied datasets can create false links and unsafe controls.
• Combine infrastructure with behavior to improve specificity.
• Revalidate before operational use and expire findings when their evidentiary basis changes.

Analyst habit: Never write “connected infrastructure” without explaining connected how, observed by whom, during which period, and why the relationship matters to this decision.

Build, test, and operationalize infrastructure hypotheses

An infrastructure hypothesis is a testable explanation of how one or more resources relate to observed activity. It may concern operational role, common control, shared provisioning, reuse, or expected future behavior. The hypothesis should be narrow enough for evidence to strengthen or weaken it.

Examples:

• sync-example.invalid was used to deliver or control Project Lantern activity during 3–12 August.
• Domain D-2 and sync-example.invalid were provisioned through a common administrative process.
• Address 203.0.113.24 is shared hosting and does not establish common control among its tenants.
• The post-block resolution change resulted from provider action rather than adversary adaptation.

Do not begin with “all connected infrastructure belongs to the same actor.” That combines several untested claims.

Generate competing explanations

For a relationship between two domains, consider:

• common operator or administrator;
• common hosting customer but different operations;
• shared hosting provider or automated platform;
• copied configuration or certificate;
• compromised infrastructure;
• reseller or affiliate relationship;
• defensive sinkhole, scanner, or researcher;
• coincidence;
• dataset or parsing error;
• historical relationship that is no longer active.

A relationship graph should preserve these alternatives rather than presenting every edge as common ownership.

Build an evidence matrix

Project Lantern analysts examine whether sync-example.invalid and Domain D-2 share common control.

The matrix shows that certificate overlap alone is weak. An uncommon path and response pattern may be more diagnostic if observed independently.

Weight evidence by uniqueness and independence

Ask two questions:

1. How unusual is this feature in the relevant environment?
2. How independently was it observed?

Potentially useful features include:

• uncommon service configuration;
• repeated path or parameter structure;
• deployment timing and lifetime;
• certificate subject, key, fingerprint, or issuance pattern;
• registration and delegation pattern;
• content, favicon, or page structure;
• protocol behavior;
• shared account, tenant, or administrative identifier;
• consistent redirect chain;
• overlap across several incidents.

Uniqueness must be demonstrated, not assumed. A rare-looking string may be a default generated by common software. A certificate fingerprint may be copied. A configuration may originate from public code.

Independent observations may include:

• direct internal telemetry;
• separate historical datasets with distinct collection methods;
• preserved service responses;
• partner evidence with direct access;
• provider confirmation under appropriate authority.

Use temporal compatibility tests

A relationship is stronger when evidence overlaps in time appropriately.

Test:

• Were both resources active during the assessed operation?
• Did shared features exist at the same time or only months apart?
• Did one resource replace another after blocking or suspension?
• Could reassignment explain the apparent continuity?
• Did certificate issuance precede service deployment plausibly?
• Is the source’s historical granularity sufficient to establish overlap?

Example:

Domains D-1 and D-2 used the same certificate, but D-2 first appeared six months after D-1 was transferred to a researcher. The overlap does not support continuous adversary control.

Validate graph edges before expansion

Infrastructure analysis can expand exponentially. Assign every candidate edge a status:

Expand from validated relationships first. Do not pivot recursively from weak associations without a decision-relevant reason.

A pivot budget can control scope:

• maximum relationship depth;
• permitted entity types;
• required minimum evidence;
• time window;
• stop condition;
• intended output.

For example:

Expand no more than two validated relationship steps from Project Lantern seed domains, limited to infrastructure active during 1–15 August, and stop when additional pivots cannot change the hunt or containment decision.

Distinguish clustering from attribution

Infrastructure analysis can support a cluster of related activity without identifying a human, organization, or state.

Use a ladder:

1. Observation: Resources share a documented feature or relationship.
2. Infrastructure cluster: Several resources likely reflect a common provisioning or operational pattern.
3. Activity cluster: Infrastructure and behavior link multiple events or incidents.
4. Common operational control: Evidence suggests the same operator or coordinated group controlled the activity.
5. Attribution: The activity is linked to a named entity with appropriate confidence and consequence-aware review.

Each level requires additional evidence. Do not jump from a shared certificate to a named actor.

Plan operational use by evidence strength

Infrastructure findings can support different actions:

A finding suitable for hunting may be too uncertain or broad for blocking.

Create an infrastructure finding record

A decision-ready finding includes:

• proposition;
• seed observation and behavioral context;
• entities and precise relationships;
• event and observation periods;
• sources, access, and lineage;
• transformations and enrichments;
• evidence supporting and challenging the hypothesis;
• alternative explanations;
• likelihood and confidence;
• intended and prohibited uses;
• shared-service and collateral risks;
• first and last observed;
• validation and expiration times;
• owner and review trigger;
• feedback and correction route.

Example:

Finding IF-12: sync-example.invalid was likely operationally related to Project Lantern host activity on 12 August, with moderate confidence. Hosts A and B contacted the domain immediately after matching script execution. Internal endpoint and DNS records independently establish the relationship. Historical resolution to 203.0.113.24 is supported from 3–12 August, but the address is multi-tenant. Use the hostname and process context for retrospective search and monitor-only detection through 15 August. Do not block the address without additional service-specific evidence. Revalidate on resolution, ownership, or certificate change.

Build warning indicators

An infrastructure hypothesis can generate warning indicators:

• new domains using a validated uncommon configuration;
• a replacement resource appearing shortly after blocking;
• reuse of a protected administrative identifier;
• a compatible certificate and service pattern during the campaign window;
• a recurring redirect chain paired with the same delivery behavior;
• provider or registration events that precede observed operations.

A warning indicator should state:

• which hypothesis it supports;
• expected observation;
• required source and coverage;
• benign alternatives;
• threshold for escalation;
• expiration or review.

Avoid alerts based solely on generic features such as domain age, registrar, country, or cloud provider.

Handle provider and partner information

Providers may have unique evidence about tenant ownership, account creation, access logs, suspension, or abuse reports. Such evidence can be decisive but requires:

• appropriate authority and request process;
• protection of personal, customer, and source-sensitive information;
• clear timestamp and account semantics;
• understanding of provider retention and visibility;
• separation of provider observation from provider interpretation;
• restrictions on onward sharing and attribution;
• validation against independent evidence where feasible.

Do not imply provider confirmation when the source only acknowledged receipt of an abuse report.

Project Lantern hypothesis outcome

The team concludes:

• The incident domain is likely related to the observed host activity during the defined window.
• The shared address is not sufficiently specific for broad blocking.
• Certificate overlap with D-2 supports a candidate infrastructure relationship but not common control.
• An uncommon response path observed independently on both domains raises the common-provisioning hypothesis.
• The resolution change after blocking could reflect provider suspension, resource rotation, or unrelated reassignment; current evidence cannot distinguish them.

The team searches historical telemetry for hostname, path, certificate, and process relationships. It monitors new compatible domains but requires behavior context before containment.

Common infrastructure-analysis failures

• Graph-size success: More nodes and edges are treated as better analysis.
• Timeless edges: Historical relationships appear permanently valid.
• Shared-service blindness: Multi-tenant infrastructure becomes malicious by association.
• Enrichment inflation: Current lookups are presented as incident-time evidence.
• Copy-count corroboration: Repeated datasets are mistaken for independent sources.
• Pivot drift: Weak edges generate unlimited exploration unrelated to a decision.
• Cluster-attribution leap: Common provisioning is treated as named identity.
• Action mismatch: Hunt-level evidence drives blocking without validation or impact review.
• No expiration: Volatile findings remain active indefinitely.

Infrastructure hypothesis checklist

• The hypothesis is testable and bounded by time, behavior, and intended use.
• Competing explanations include shared services, copied configuration, compromise, error, and historical change.
• Evidence is evaluated for uniqueness, independence, and temporal compatibility.
• Graph edges have precise types, direction, source, time, status, and limits.
• Expansion follows validated relationships and a pivot budget.
• Clustering is separated from common control and attribution.
• Operational use matches evidence strength and collateral risk.
• Findings include validity, expiration, review, and correction controls.
• Warning indicators specify hypotheses, sources, benign alternatives, and thresholds.

Key takeaways

• Infrastructure hypotheses explain operational relationships; they do not automatically establish ownership or identity.
• Compare common control against shared platforms, copied configuration, compromise, coincidence, and data error.
• Favor temporally compatible, uncommon, independently observed evidence.
• Control graph expansion with validated edges, bounded pivots, and decision relevance.
• Separate infrastructure clusters, activity clusters, common control, and attribution.
• Match enrichment, hunting, monitoring, alerting, blocking, sharing, and attribution to different evidence thresholds.
• Expire and revalidate volatile findings.

Analyst habit: Before expanding an infrastructure graph, complete this sentence: If this relationship is validated, it will change [specific hunt, containment, sharing, or assessment decision].