FinWiki
日EN中

Forensic Identity Anchor Chain for a Team's True Identity — Synthesizing Multi-Source Fingerprints

Confidence: Likely Updated 2026-05-26 Review by 2026-09-22 Sources 3 Machine-translated Original (JA)
#security/forensic#security/identity#security/dd
On this page

Wiki route

This entry sits under FinWiki index. Read it with bytecode forensic for peer context and systems index for the broader infrastructure boundary.

[!info] TL;DR When the public-facing structure (LinkedIn company page / official site about / PR release) does not match the people actually writing the code, synthesize 6 independent fingerprint sources → build a single-thesis identity chain → lock the separation structure of “public-facing vs real team.” Combined with the cluster labels of Global crypto-asset forensics-vendor layer — Chainalysis / Elliptic / TRM / Crystal comparison, a complete attribution can be formed.

6 Independent Fingerprint Sources

  1. TLS certificate SANs — the Subject Alternative Names within a domain certificate · the same ops base tends to share the same certificate or issuing authority
  2. Concentration of GitHub account registration times — multiple accounts registered consecutively within 1 hours = a sock-puppet signal
  3. Email domain preference — ProtonMail / iCloud / own domain vs Gmail · the team’s overall preference tends to align
  4. Language of names on the LinkedIn company page — a mix of West African / Southeast Asian / Indian / Chinese / Japanese names
  5. Language of the GitHub commit author name — the name field of actual commits (contrasted with the public-facing names on LinkedIn)
  6. Exposure from CLI / config paths — config paths in the home directory, remnants of SSH known-hosts, document metadata, the author field of PDFs

Synthesis logic

  • Public-facing vs real-team determination: source 4 (LinkedIn name) ≠ source 5 (commit author name) + source 3 (email domain preference) → a binary separation
  • Sock-puppet determination: source 2 (concentration of registration times) + source 5 (email overlap between “independent” accounts) → multiple accounts of the same person — attribution inference for large exchange incidents like DMM Bitcoin Lazarus hack relies precisely on this kind of multi-account cluster-overlap analysis
  • Individual identity anchor: source 1 (TLS) ∩ source 6 (CLI path) → a single-thesis dev identity — the result of this layer can connect directly to the sanctions-list matching process of Chain-Level OFAC Freeze = Dollar Chain-Level Hegemony

Anti-pattern

Do not assert identity on a single thesis (e.g., concluding from LinkedIn1件 alone) · always cross-check with 3 or more independent sources.

When to Use

  • Cases where a project claims to be a “global team,” but the code style / comment language is inconsistent
  • Cases where the same email appears in the commits of multiple “independent companies / outsourcers”
  • Cases where the LinkedIn name and the Whitepaper author / commit author name are in completely different languages

When NOT to Use

  • The project is public and transparent (GPG-signed / has a public identity)
  • An individual’s open-source project (no need to contrast against a public face)
  • Cases where you only do code-quality DD and do not verify the team’s authenticity

Provenance

  • Case study (vaporware audit): multiple GitHub accounts registered in a concentrated short window + the language of names on the LinkedIn company page vs the language of the commit author name did not match + the metadata author of the Whitepaper PDF + CLI path remnants + own-domain email · the separation of public-facing / real team was locked through cross-checking of multiple anchors
  • The same kind of technique is also applied to ex post attribution inference: see the leads for attacker tracing in Coincheck Nem Hack Detailed Analysis or JP VASP incident history