SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsre-attribution

re-attribution

Agents & models

View repository

Updated 10-15 21:34

About this skill

Threat Attribution (APT Attribution)

When to use / when not to use

  • Use: intelligence attribution requests ("who did it"), multi-incident linkage (determining whether several incidents are the same activity), infrastructure correlation analysis, reasoning from samples/capabilities to attackers
  • Use: attacker profiling of a victim environment (synthesis of timeline, TTPs, infrastructure characteristics)
  • Use: same-group activity investigation (one incident → find other incidents with the same infrastructure/same capabilities, correlate first then assign severity)
  • Don't use: single IOC lookups (go to [[re-ti]]); malicious behavior determination (go to [[re-behavior]])
  • Don't use: judicial chain of evidence (criminal standards are higher than intelligence attribution; the conclusions of this skill cannot be used directly as judicial evidence, see [[gotchas]])
  • Don't use: organization-level attribution when there is only single-corner evidence (samples alone or domains alone do not support an attribution claim; for branch decisions see [[decision-tree]])

Tool preparation

Correlation query tools (Passive DNS / Certificate Transparency / Whois)

  • whois CLI (registration information/ASN ownership): Linux apt install whois / dnf install whois；macOS brew install whois; on Windows use the WSL branch (see [[re-analyze/platform-tips]])
  • python-whois (Python module): multi-platform pip install python-whois; verify: python3 -c "import whois"
  • dnsx (DNS enumeration): the official channel is the Go binary——GitHub projectdiscovery/dnsx releases or go install github.com/projectdiscovery/dnsx/cmd/dnsx@latest; verify dnsx -version(the PyPI package of the same name is unrelated to the official tool, don't mix them up)
  • Certificate Transparency logs: crt.sh web query (public service, search by domain/certificate fingerprint)
  • ASN ownership query:whois -h whois.cymru.com <IP> returns the AS number and ownership (Team Cymru public interface)

MISP (intelligence correlation and sharing)

  • Docker deployment (official install script/image,apt install misp does not exist in distribution repositories) or a lightweight alternative (local CSV/graph files)
  • Verify: logging into the MISP UI allows creating/retrieving events (for the lightweight alternative, self-check with a data import script)

Graph analysis (infrastructure relationships)

  • Multi-platform: pip install networkx(Python graph analysis); verify: python3 -c "import networkx"

Procedure

Execute in order; desensitize all content (red line: do not point to specific organizations/victim identities, use only code names and abstract descriptions).

  1. Diamond Model positioning：

    • Four corners: victim (already identified) / infrastructure (C2 domains/IPs/certificates) / capability (tools/samples/exploits) / adversary (to be inferred)
    • Activity line: model incidents as tuples (time, adversary, capability, infrastructure, victim); multiple incidents are linked into an activity line by shared elements
    • Metadata elements: time window, victim domain, industry attributes——used for clustering and timelines (not evidence on their own)
    • Four-corner information table fields: a column for each corner (known items/unknown items/source/query time); unknown items are the attribution gaps
    • Output: four-corner known-information table + missing corners (attribution targets)
    • Rule: reasoning can only begin with two or more corners; a single corner (samples only) does not support an attribution claim (for criteria see [[decision-tree]])
    • Single-corner output form: when there is only 1 corner, deliver at the "intelligence lead" level (IOC list + characteristic description), mark "not entered into attribution", and do not write organization names

  2. Infrastructure Graph：

    # 域名/IP/证书关联聚类（示例流程，工具可替换）
# 1) 收集 C2 域名/IP → whois 注册信息（注册者/邮箱/NS/ASN）
# 2) 证书透明日志（crt.sh）查共用证书 → 关联其他域名
# 3) dnsx 主动枚举关联子域/NS 记录（被动 DNS 接口看解析历史）
# 4) networkx 图聚类：共享注册者/证书/NS/ASN 的节点合并
    • Sort clustering features by discriminative power: unique registration email/certificate > shared NS/ASN > same hosting provider
    • Passive DNS focus points: domain first resolution time, resolution IP range switch history, historical NS changes (registrant operational habit characteristics)
    • IP range characteristics: the purpose/registration time of other domains within the range (clustering of similar activity is a weak clue; bulk registration by hosting providers must be excluded)
    • Whois privacy protection: registration information may be anonymous (common after GDPR)—when registrant fields are unavailable, downgrade to cross-referencing certificate/NS/behavioral characteristics, and mark the registration information blind spot
    • Domain similarity (same suffix/typosquat) serves only as a weak clue: both registrar and registration time can be forged
    • Coexistence on jump hosts/hosting providers cannot be used as attribution evidence (see Pitfall 1 and [[gotchas]])

  3. Capability and Sample Attribution：

    • Code reuse: similarity of strings/functions/resources/import tables between samples (unique strings take priority)
    • TTP comparison: align behavior patterns with known activity (for alignment methods, refer to [[re-behavior]] and ATT&CK mapping)—first coarse alignment (major technique category), then fine alignment (port/parameter/encryption details)
    • Timeline: activity window alignment (first normalize to UTC to verify time zone and time source, see Pitfall 6)
    • Unique characteristics take priority: distinctive strings/compilation features/language habits (more discriminative than generic TTPs)
    • Sample family names are analyst-assigned names, not attribution evidence (naming is determined by analysis habits, see [[gotchas]])
    • Output: capability evidence table (each piece of evidence → supports/refutes the hypothesis, with traceable sources)

  4. Confidence Grading：

    • Low: a single type of weak evidence (generalized characteristics, such as only sharing a hosting provider)
    • Medium: cross-referencing two independent types of evidence, or a single type of strong evidence (multiple unique characteristics)
    • High: three or more types + consistent timeline + no contradictory evidence
    • Determination: score by evidence type × strength; for rules and counterexamples, see the evidence grading table in [[decision-tree]]
    • Wording standards: low → "associated activity"; medium → "suspected same activity"; high → "highly suspected attribution"; do not write absolute assertions (see the boundary statement in [[gotchas]])
    • Rule: when there is no high-confidence evidence, state "associated activity" rather than "attributed organization"; clearly list unresolved counterevidence
    • Do not set a "confirmed" level: intelligence attribution has no 100% assertion, and even the highest level retains hypothetical premises (e.g., "assuming this infrastructure has not been hijacked")

  5. Report：

    • Structure: conclusion (graded statement) → evidence chain (evidence for each corner + sources) → basis for confidence → counterevidence and unresolved items → method boundaries (what cannot be determined)
    • Template (redacted version): 
      # 归因报告（内部）
- 结论：<等级> —— 与 <代号> 活动为同一活动方（置信度：中）
- 证据链：1) 唯一注册邮箱（whois，查询时间） 2) 共用证书（crt.sh） 3) 代码唯一字符串（样本对照）
- 反证/未决项：时间线缺口；注册信息匿名（GDPR）
- 方法边界：未验证 C2 行为；无法判定项清单
    • Conclusion and evidence cross-checked against [[re-analyze/analysis-contract]] review format for archiving (conclusion/evidence/confidence)
    • Redaction: do not publicly disclose victim identities/real organization names (use code names), and do not issue excessive attribution statements; keep external messaging and internal conclusions separate (layered output)
    • Redaction checklist: replace all victim identities/organization names/domains/IPs with code names; mask hostnames/usernames in screenshots; recheck once more before citing original intelligence

Cross-domain Fusion

  • [[re-ti]]: Intelligence Input (IOC Lookup and Context)
  • [[re-ioc]]: Indicator Extraction (Domains/IPs/Hashes)
  • [[re-behavior]]: Behavioral Evidence (TTP Alignment)
  • [[re-protocol]]: C2 Protocol Analysis (Infrastructure Characteristics)
  • [[re-hunting]]: Attribution Hypotheses Can Be Converted into Hunting Hypotheses ("If the same activity actor enters the environment, what will appear in telemetry?")
  • [[re-feedback]]: Accumulation of Attribution Case Experience (after sanitization)
  • [[re-analyze/analysis-contract]]: Conclusion Delivery Format

Common Pitfalls and Traps

  • Infrastructure Overlap Leads to Misattribution: Phenomenon—two activity sets sharing C2 infrastructure are merged into one group; Cause—shared hosting/compromised infrastructure; Countermeasure—distinguish between "shared" and "controlled" evidence (registration information vs. hosting only), and downgrade shared-type evidence to weak evidence
  • Jump Host ≠ Attribution: Phenomenon—activity routed through a third-party jump host is attributed to the jump host's owner; Cause—confusing the path; Countermeasure—only count "control plane evidence" (registration/configuration/unique characteristics) toward attribution
  • Inflated Confidence: Phenomenon—a single unique trait (rare string) is taken as high confidence; Cause—a single piece of evidence is strong but lacks cross-validation; Countermeasure—grade according to Step 4, with a single category of weak evidence capped at "Low" and a single category of strong evidence capped at "Medium"
  • Capability Sharing Is Misread: Phenomenon—two activity sets sharing tools (public tools/rental platforms) are attributed to one group; Cause—capability is a commoditized resource and is not unique; Countermeasure—tool-type evidence can only be weak evidence and must be combined with infrastructure/timeline evidence
  • No Evidence ≠ Exclusion: Phenomenon—misaligned timelines or inability to find records leads to a judgment of "irrelevant"; Cause—missing passive data, evidence not publicly disclosed; Countermeasure—label it as "not found" rather than "does not exist," and list timeline gaps as counterevidence
  • Timestamp/Log Anti-Forensics: Phenomenon—attackers forge timestamps/delete logs to misalign the timeline; Cause—active obfuscation; Countermeasure—cross-check multiple time sources (file time/log time/traffic time) and label credibility
  • Sanitization Red Line: Phenomenon—real victim/organization identities appear in the report; Cause—copying raw intelligence without processing it; Countermeasure—check item by item before reporting (mandatory red line)
  • Report Scope Leakage: Phenomenon—internal conclusions are cited as external statements; Cause—no tiering of scope; Countermeasure—separate versions for internal reports and external summaries, with external summaries retaining only grading and an evidence overview
  • Reasoning Chain Is Not Reviewable: Phenomenon—conclusions cannot be traced back to evidence; Cause—assumptions and intermediate judgments are not recorded; Countermeasure—archive assumptions/evidence/grading throughout each step (path + time), and attach an evidence index to the report
  • For scenario branches, the evidence grading table, and more counterexamples, see [[decision-tree]] / [[gotchas]]