Tracing the Untraceable: Language Pattern Analysis, IP Attribution, and Decloaking Techniques in Fraud Investigation | Brian Curry

A practitioner’s deep dive into the defensive disciplines fraud teams, threat-intelligence analysts, and digital forensic investigators use to identify online fraudsters and other bad actors — the methods, the math, the tooling, the code, and the legal guardrails that keep this work on the right side of the line.

Who this is for, and the one rule that governs all of it

This article is written for blue-team analysts, trust-and-safety and fraud teams, OSINT investigators, security researchers, and journalists. The techniques here are the ones used to attribute scams, link sockpuppet accounts, trace phishing infrastructure, and assemble evidence packages for law enforcement.

Online fraud is not a niche problem. Business email compromise, romance and “pig-butchering” scams, account-takeover rings, and coordinated review fraud move enormous sums and ruin lives, and the people behind them work hard to stay invisible — rotating infrastructure, hiding behind VPNs and residential proxies, and spinning up disposable identities faster than any single platform can ban them. Attribution is the craft of making them visible anyway, using nothing but the traces they leave and the data you lawfully hold.

Before any of it, the governing rule: you investigate using your own data, public data, and lawfully obtained data — and you do not break into anyone’s systems to do it. In the United States, “hacking back” — accessing an attacker’s computer without authorization, even to retrieve your own stolen files — is a crime under the Computer Fraud and Abuse Act (18 U.S.C. § 1030), and most other countries have equivalent statutes. A former NSA programmer’s summary is the cleanest articulation of the boundary: if you’re executing code on someone else’s machine, you’re hacking. The proposed “Active Cyber Defense Certainty Act” has been floated repeatedly since 2017 to carve out narrow exceptions for attribution beacons, but as of 2026 it has not become law, and even its drafters wrap it in warnings about misattribution and escalation.

Everything below operates inside that line. Where a technique edges toward it, the article says so explicitly.

Part I — The attribution mindset

Attribution is probabilistic, not binary. You are almost never going to get a confession-grade “this is the person.” What you build instead is a weight of converging evidence: a writing style that matches, an IP that resolves to the same hosting provider, a reused username, a payment trail, a time-zone pattern in posting behavior. Each signal is weak alone; together they form a case. The skill is not finding one smoking gun — it’s combining many weak indicators correctly and knowing how confident the combination actually licenses you to be.

Grade your confidence, and grade your sources

Borrow two habits from intelligence tradecraft.

First, label each claim low / medium / high confidence, and state why: “Likely the same author (medium confidence: strong stylometric match on a short sample, no corroborating infrastructure).” Confidence is a claim about evidence, not a feeling.

Second, grade the source of each piece of evidence separately from the claim it supports. The NATO/Admiralty system does this with a two-axis code — source reliability (A–F) and information credibility (1–6) — so that “reliable source, uncorroborated claim” and “dubious source, corroborated claim” don’t get flattened into the same mushy “probably.” A passing DKIM signature is an A-grade source; a forum post claiming to know the scammer’s real name is an E. Keeping the axes separate stops you from laundering a weak source into a strong conclusion just because it fits.

Reason in hypotheses, not in confirmations

The single biggest source of wrongful attribution — and real-world harm, when an innocent person gets named — is settling on a theory early and then collecting only what fits it. The discipline that fights this is Analysis of Competing Hypotheses (ACH), formalized by Richards Heuer at the CIA: list all the plausible explanations up front, then score each piece of evidence by how well it discriminates between them. Evidence consistent with every hypothesis is worthless for attribution no matter how damning it feels. The hypothesis you want to advance is the one with the least evidence against it, not the most evidence for it.

Beware the prosecutor’s fallacy

The most dangerous statistical error in attribution is confusing “the probability of this evidence if the suspect is guilty” with “the probability the suspect is guilty given this evidence.” A stylometric model that’s “95% accurate” does not mean a flagged author is 95% likely to be your person. If you’re scanning ten thousand accounts to find one operator, even a tiny false-positive rate produces a pile of innocent matches that can swamp the true one. Base rates dominate. Any time you run a matcher across a large population, the right question is not “how good is the model” but “given how rare the target is, how many false hits will this produce, and how do I corroborate past them.”

Preserve chain of custody from minute one

If this might ever reach a court — or even an internal disciplinary process — screenshots are not enough. Hash your evidence, record timestamps and time zones, keep original files untouched, and log every step you take. A capture tool like Hunchly exists specifically to do this for web-based investigations, maintaining a tamper-evident record of what you saw and when. Build every investigation as though a defense attorney will cross-examine it, because the good ones do.

The frameworks that structure the work

Three reference models give the work shape. The Diamond Model of Intrusion Analysis says every event has four linked vertices — adversary, capability, infrastructure, victim — and that the core motion of attribution is pivoting from one known vertex to discover another. MITRE ATT&CK catalogues adversary technique so you can describe how an actor operates in a shared vocabulary, and MITRE Engage frames deliberate deception and adversary engagement. The Cyber Kill Chain and Meta’s Online Operations Kill Chain are complementary lenses — the latter far better suited to influence operations and coordinated inauthentic behavior than to malware intrusions.

Part II — Language pattern analysis (stylometry and forensic linguistics)

The premise

Every writer has unconscious habits: how often they reach for function words like the, of, and, to; their sentence-length rhythm; their punctuation and capitalization tics; their characteristic misspellings and spacing. These habits are largely invisible to the writer, hard to suppress deliberately, and — crucially — measurable. That measurable signature is the basis of stylometry.

The discipline has a long pedigree. Mosteller and Wallace used function-word frequencies to resolve the disputed authorship of The Federalist Papers in 1964. In 2013, Patrick Juola applied the same family of methods to confirm that “Robert Galbraith,” author of The Cuckoo’s Calling, was J. K. Rowling. The fraud-investigation application points the same machinery at a different target: Are these five romance-scam messages, posted from five different accounts, written by the same person?

Why it works: the unconscious signal

The reason stylometry is hard to defeat is that its strongest signals are the words writers pay the least attention to. You choose your nouns and verbs deliberately — they carry your meaning — so they’re easy to change when you want to disguise yourself. But the connective tissue of language, the function words and punctuation rhythms, runs on autopilot. Two people writing about the identical topic will still differ measurably in how they distribute that versus which, how often they start sentences with and, whether they double-space after a period, how they deploy commas. That’s why a good stylometric feature set leans on the parts of writing that are content-independent and habitual rather than the parts that are deliberate and topical.

The features that carry the signal

In rough order of how much forensic weight they tend to carry:

Function words — the closed-class words (articles, prepositions, conjunctions, pronouns, auxiliaries) an author can’t easily avoid and rarely thinks about. The workhorse of classical stylometry.
Character n-grams — sequences of three to four characters. Quietly one of the strongest features available, because they capture spelling, morphology, and punctuation habits all at once, and they survive short texts and noisy input surprisingly well.
Punctuation and orthography — Oxford comma or not; single versus double spacing; emoji, ellipsis, and capitalization habits; British versus American spelling.
Syntactic structure — part-of-speech sequences, sentence complexity, clause patterns.
Idiosyncratic errors — the same misspelling (definately, recieve), the same non-native construction, the same keyboard-layout typo. These are gold, because they’re rare and personal.
Vocabulary richness — type-token ratio and related lexical-diversity measures.

Attribution versus verification, closed set versus open set

One conceptual distinction does more to prevent bad conclusions than any feature choice: know which problem you’re actually solving.

Authorship attribution asks: of these known candidates, who wrote the questioned text? It assumes the true author is in your candidate set — a closed-set problem. The model will always name someone, so if the real author isn’t among your candidates, it will confidently name the wrong one.

Authorship verification asks: did this specific person write the questioned text, yes or no? It’s an open-set problem, and it’s the honest framing for most investigations, because in the real world you usually can’t guarantee your suspect is the author at all. Verification forces the model to be able to say “none of the above,” which is exactly the answer that protects innocent people. If you only ever run closed-set attribution, you’ve built a machine that cannot exonerate — treat its output accordingly.

The methods, from simplest to heaviest

Burrows’s Delta — a distance metric over z-scored frequencies of the most common words. The classic, interpretable baseline, best for comparing a questioned text against a handful of candidate authors when you have decent-length samples.
Supervised classifiers — SVM, logistic regression, or random forest over character n-gram and function-word vectors. Reach for this when you have labeled writing samples per candidate and want a trainable, evaluable model.
Stylometric embeddings / deep models — RNN- or transformer-based models that learn a style space (e.g., the CLAVE approach for code authorship). Suited to large candidate sets or code authorship; state-of-the-art source-code attribution reaches the low-90s in accuracy across thousands of programmers.
LLM-based attribution — fine-tuned LLMs, or “perplexity-of-authorial-language-model” scoring (Huang, Murakami & Grieve, 2025). Used for research-grade verification, and increasingly to flag machine-generated text.

Eder, Rybicki, and Kestemont’s stylo package documentation and Efstathios Stamatatos's 2009 survey, "A Survey of Modern Authorship Attribution Methods," are the canonical orientations; a 2022 survey by Tyo, Dhingra, and Lipton ("On the State of the Art in Authorship Attribution and Authorship Verification") is the best single map of where these methods actually stand on standardized benchmarks — worth reading before you trust any vendor's accuracy claim.

How Burrows’s Delta actually works

Delta is worth understanding in detail because it’s interpretable, which matters when you have to defend a conclusion. The recipe: take the N most frequent words across your reference corpus (often 100–500). For each one, compute its relative frequency in each document, then convert those frequencies to z-scores — subtract the mean and divide by the standard deviation across the corpus. The z-scoring is the whole trick: it puts every word on the same scale, so a common word like the doesn’t drown out a discriminating-but-rarer word like upon. Delta is then just the average absolute difference between the z-scored profiles of two documents. Small Delta means the two texts use their common words in similar proportions; large Delta means they don’t. It’s a nearest-neighbor method dressed in statistics, and its transparency is exactly why it’s survived sixty years.

A working classifier you can build today

This is a legitimate, defensive analysis pipeline: it takes labeled writing samples you already hold (messages tied to known accounts on your own platform) and scores an unknown sample against them, combining character n-grams with function-word frequencies — the pairing that consistently performs well.

# pip install scikit-learn
# Stylometric authorship attribution: char n-grams + function-word frequencies.
# Train on labeled samples you lawfully hold; score an unknown text against them.

import re
import numpy as np
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.pipeline import Pipeline, FeatureUnion
from sklearn.svm import LinearSVC
from sklearn.calibration import CalibratedClassifierCV
from sklearn.base import BaseEstimator, TransformerMixin

FUNCTION_WORDS = """a about above after again against all am an and any are as at be
because been before being below between both but by can did do does doing down during
each few for from further had has have having he her here hers him his how i if in into
is it its just me more most my no nor not now of off on once only or other our out over
own same she should so some such than that the their them then there these they this
those through to too under until up very was we were what when where which while who whom
why will with you your""".split()

class FunctionWordCounts(BaseEstimator, TransformerMixin):
    """Relative frequency of each function word per document."""
    def fit(self, X, y=None): return self
    def transform(self, X):
        rows = []
        for doc in X:
            tokens = re.findall(r"[a-z']+", doc.lower())
            n = max(len(tokens), 1)
            counts = {w: 0 for w in FUNCTION_WORDS}
            for t in tokens:
                if t in counts: counts[t] += 1
            rows.append([counts[w] / n for w in FUNCTION_WORDS])
        return np.array(rows)

features = FeatureUnion([
    ("char_ngrams", TfidfVectorizer(analyzer="char_wb",
                                    ngram_range=(3, 4),
                                    min_df=2, sublinear_tf=True)),
    ("func_words", FunctionWordCounts()),
])

clf = CalibratedClassifierCV(LinearSVC(C=1.0))  # calibrated -> usable probabilities
model = Pipeline([("features", features), ("clf", clf)])

train_texts = [
    "i definately think we should of met sooner, you seem real genuine to me",   # author A
    "honestly i feel like fate brought us together, i was meant to find you",     # author A
    "Please find attached the revised invoice. Kindly remit payment by Friday.",   # author B
    "Per my previous email, the wire details remain unchanged. Confirm receipt.",  # author B
]
train_labels = ["scammer_A", "scammer_A", "bec_actor_B", "bec_actor_B"]
model.fit(train_texts, train_labels)

unknown = "i definately feel we was ment to meet, this is fate bringing us close"
probs = model.predict_proba([unknown])[0]
for author, p in sorted(zip(model.classes_, probs), key=lambda x: -x[1]):
    print(f"{author:>14}: {p:.2%}")
# Treat the output as a lead, not proof. Report confidence and sample size.

Finding campaigns: clustering when you have no labels

Classification answers “which known author wrote this.” But the more common fraud question is the reverse: here are 200 “independent” accounts — how many real people are behind them? For that you cluster unlabeled text by style and let the groups fall out. This is the engine of sockpuppet and coordinated-inauthentic-behavior detection.

# pip install scikit-learn scipy
# Unsupervised authorship clustering: surface "these N accounts are really K people."
# Operates on text you lawfully hold (e.g., messages tied to accounts you administer).

import numpy as np
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.metrics.pairwise import cosine_similarity
from scipy.cluster.hierarchy import linkage, fcluster
from scipy.spatial.distance import squareform

def cluster_authors(texts, labels, distance_threshold=0.55):
    # Char 3-4 grams capture style largely independent of topic
    vec = TfidfVectorizer(analyzer="char_wb", ngram_range=(3, 4),
                          min_df=1, sublinear_tf=True)
    X = vec.fit_transform(texts)
    dist = 1.0 - cosine_similarity(X)
    np.fill_diagonal(dist, 0.0)
    dist = np.clip(dist, 0.0, None)
    Z = linkage(squareform(dist, checks=False), method="average")
    cluster_ids = fcluster(Z, t=distance_threshold, criterion="distance")
    groups = {}
    for label, cid in zip(labels, cluster_ids):
        groups.setdefault(int(cid), []).append(label)
    return groups

accounts = {
  "user_01": "honestly i feel like fate brought us together babe, i was ment to find you",
  "user_02": "Per my previous email, the wire details are unchanged. Confirm receipt today.",
  "user_03": "i definately think we was ment to meet, this is fate pulling us close",
  "user_04": "Kindly remit payment by Friday. Find the revised invoice attached, regards.",
  "user_05": "fate keeps bringing us back together, i feel like we was ment for this",
}
for cid, members in cluster_authors(list(accounts.values()), list(accounts.keys())).items():
    print(f"cluster {cid}: {members}")
# Expect 01/03/05 to group (one romance-scam author) and 02/04 (one BEC author):
# five accounts, two operators. The threshold is a knob — validate it, don't trust it blind.

The distance_threshold is the dangerous knob: set it loose and unrelated people merge; set it tight and one person splinters into several clusters. Never ship a threshold you haven't validated against known-answer data.

Evaluating a stylometric model honestly

A stylometric result you can’t validate is a guess with a percentage sign. Three rules separate real evaluation from self-deception.

First, hold out authors, not just documents. If you split a single author’s messages across train and test, you’re measuring whether the model recognizes that author’s topics, not their style — and it’ll look brilliant and be useless on new authors. Test on writers the model has never seen.

Second, watch for topic leakage. If author A only ever wrote about crypto and author B only about romance, your classifier may be a topic detector wearing a stylometry costume. Character n-grams help, but the honest test is cross-genre or cross-topic: train on one subject, test on another.

Third, report the metrics that matter for your base rate. Accuracy is nearly meaningless when the target is rare; precision, recall, and especially the false-positive rate at your operating threshold are what tell you how many innocent people a population-wide scan will flag. Calibrate the probabilities (the classifier above does) so a “70%” actually means something.

Tools of the trade

For heavier work, the established tooling is stylo (the R reference package for Delta-family analysis and clustering); JGAAP and JStylo (the Juola-lineage Java toolkits); and Python pipelines built on scikit-learn with NLTK or spaCy for feature extraction.

Fraud-specific applications

Sockpuppet and ban-evasion detection — linking a “new” account to a banned actor by writing style.
Romance-scam and pig-butchering linkage — script-driven scams reuse phrasing across victims; stylometry plus exact-phrase matching clusters the campaign and reveals its true headcount.
Business Email Compromise — distinguishing the real executive’s writing from the impostor’s, and linking impostor messages across targets.
Coordinated inauthentic behavior — detecting that “200 independent reviewers” are three people.
AI-generated content flags — a fast-moving area where stylometry can flag machine-generated text in short samples, though detectors are brittle and adversarially defeatable, so treat them as one signal among many.

Adversaries fight back — and so do machines

Stylometry has an adversarial twin: stylometric obfuscation. A motivated author can deliberately flatten their style, imitate someone else, or round-trip their text through machine translation to scramble the function-word fingerprint. Research tools have demonstrated each of these. The newest wrinkle is the large language model: ask one to “rewrite this in a neutral voice” and much of the personal signal evaporates, while asking it to “write like person X” can fabricate a plausible imitation. This cuts both ways for investigators. It means a clean stylometric match is weaker evidence than it used to be (the absence of a match proves little, since obfuscation is easy), and it makes machine-generated-text detection — itself a stylometry problem — a live and unstable research frontier rather than a solved tool you can lean on.

The limitations — read these before you act on a match

Stylometry is probabilistic signal, not forensic proof. Every serious tool says so in its own documentation.
Short texts degrade it badly. A two-line message carries little reliable signal; reliability climbs with length and sample count.
Cross-genre and cross-language comparisons are far weaker than like-for-like.
It is adversarially defeatable, as above.
A match is a lead that justifies further investigation, never the sole basis for naming a human being.

Part III — IP tracing and infrastructure attribution

Start with what arrives at your door: email headers

For phishing, BEC, and scam email, the headers are the richest free evidence you have, sitting in messages you lawfully received. The Received: chain records each mail server that handled the message, listed newest-first, so you read it bottom-to-top to follow the path of travel. The earliest trustworthy Received line — and legacy headers like X-Originating-IP — can reveal the originating host. The caveat is "trustworthy": a sender controls the headers their own systems write, so the bottom hops can be forged. The hops you can trust are the ones added by infrastructure you or reputable intermediaries control — typically the upper portion of the chain. Reasoning about which hops to believe is half the skill.

Equally important are the authentication results. SPF checks whether the sending IP is authorized to send for the envelope domain. DKIM cryptographically signs the message with the signing domain’s key, so a valid signature ties the message to that domain. DMARC ties SPF and DKIM back to the visible From: and tells receivers what to do on failure. A forged sender that fails SPF and DKIM tells you the From: is spoofed; a passing DKIM signature is strong, A-grade evidence that the message really originated from the signing domain's infrastructure.

# Parse an .eml file: walk the Received chain, pull originating IPs and auth results.
import email, re
from email import policy

def analyze_eml(path):
    with open(path, "rb") as f:
        msg = email.message_from_binary_file(f, policy=policy.default)

    print("From:      ", msg.get("From"))
    print("Reply-To:  ", msg.get("Reply-To"))      # mismatch with From is a classic flag
    print("Return-Path:", msg.get("Return-Path"))

    for h in ("Authentication-Results", "Received-SPF", "DKIM-Signature"):
        if msg.get(h):
            print(f"{h}: {msg.get(h)[:200]}")

    received = msg.get_all("Received", [])
    ip_re = re.compile(r"[\[\(]?(\d{1,3}(?:\.\d{1,3}){3})[\]\)]?")
    print("\n--- Received chain (origin -> destination) ---")
    for hop in reversed(received):
        ips = ip_re.findall(hop)
        print(f"  IPs {ips}  |  {' '.join(hop.split())[:160]}")

    for h in ("X-Originating-IP", "X-Sender-IP", "X-Mailer", "User-Agent"):
        if msg.get(h):
            print(f"\n{h}: {msg.get(h)}")

# analyze_eml("suspicious_message.eml")

From an IP to an organization: WHOIS, RDAP, ASN, DNS

Once you have a candidate IP or domain, enrich it from public registries. RDAP (the structured, modern successor to WHOIS) tells you who registered a domain or owns an IP block. An ASN lookup tells you which Autonomous System — which network operator or hosting provider — the IP belongs to, and a known bulletproof-hosting ASN is itself a signal. Reverse and forward DNS often betray the provider or even the customer through naming conventions. Passive DNS gives you historical resolution data, so you can see what a domain pointed to last month — which is how you connect burned infrastructure to its replacement. And Certificate Transparency logs (searchable at crt.sh) leak subdomains and link sibling domains registered by the same actor.

# pip install ipwhois dnspython requests
# Enrich an IP from PUBLIC sources only. No access to the target is attempted.
from ipwhois import IPWhois
import dns.resolver, dns.reversename, requests

def enrich_ip(ip):
    out = {"ip": ip}
    try:
        rdap = IPWhois(ip).lookup_rdap(depth=1)
        out["asn"] = rdap.get("asn")
        out["asn_org"] = rdap.get("asn_description")
        out["network"] = rdap.get("network", {}).get("name")
        out["country"] = rdap.get("asn_country_code")
    except Exception as e:
        out["rdap_error"] = str(e)
    try:
        rev = dns.reversename.from_address(ip)
        out["ptr"] = str(dns.resolver.resolve(rev, "PTR")[0])
    except Exception:
        out["ptr"] = None
    try:
        geo = requests.get(f"http://ip-api.com/json/{ip}", timeout=5).json()
        out["geo"] = {k: geo.get(k) for k in
                      ("country", "regionName", "city", "isp", "org", "proxy", "hosting")}
    except Exception:
        pass
    return out

# print(enrich_ip("8.8.8.8"))

Geolocation and the proxy problem — manage your expectations

IP geolocation is coarse and frequently wrong. It’s reliable to the country level, roughly to region, and unreliable to “street address” — anyone selling you a pinpoint home address from an IP is selling you a liability. Several structural realities make IP-equals-person a fallacy: carrier-grade NAT means thousands of subscribers can share one public IP; mobile IPs hop and recycle constantly; corporate and campus networks egress hundreds of users through a handful of addresses. And serious actors deliberately route through VPNs, residential proxies, Tor, or compromised hosts, so the address you see is an exit node, not a person.

Modern enrichment services (and the proxy/hosting flags in the script above) will tell you that an IP is an anonymizing relay — useful intelligence in itself — but they won't pierce it. Piercing it lawfully requires the cooperation of the relay operator or legal process served on the provider, which is the realm of law enforcement, not your investigation.

Pivoting infrastructure: how reuse betrays an operator

This is where attribution becomes powerful, and it works because operators are lazy in predictable ways. People who run many “unrelated” scam sites reuse things: the same TLS certificate or self-signed cert fingerprint, the same favicon, the same analytics or ad-network ID embedded in the page, the same unusual server banner, the same registration pattern. Search engines for internet-facing hosts — Shodan and Censys — let you find every other machine sharing one of those artifacts. Passive DNS and Certificate Transparency let you find every domain that ever pointed at an IP and every cert that ever covered a domain. A single reused Google Analytics ID across forty “independent” storefronts ties them to one operator more reliably than any IP, because the operator put it there deliberately and forgot. The logic is always the same: find the artifact the adversary didn’t think to vary, then enumerate everything that shares it.

Part IV — Building an attribution pipeline

For anyone with a data-engineering background, the most natural way to scale this work is to stop doing it by hand and build a pipeline — because attribution is fundamentally an entity-resolution problem over heterogeneous signals, which is a data problem you already know how to solve.

The shape is familiar. Ingest raw signals from the sources you lawfully hold — message text, email headers, IP and infrastructure observations, account metadata, timestamps. Normalize them into a common schema (an observation has a type, a value, a source, a confidence, and a timestamp). Resolve entities by linking observations that share a strong identifier — a reused username, a wallet address, a DKIM domain, a favicon hash — into candidate clusters representing one actor. Score each link with a weight reflecting how discriminating it is (a shared residential-proxy IP is weak; a shared idiosyncratic misspelling plus a shared analytics ID is strong), and propagate those weights into an overall confidence per cluster. Surface the clusters with their evidence and confidence for a human to review — never to auto-act.

Two design principles keep such a pipeline honest. Weight signals by their discriminating power, not their availability: the easy-to-collect signals (IP, user-agent) are usually the weak ones, and over-weighting them is how you manufacture false links at scale. And make every cluster explainable — store the specific observations that drove each link, so a reviewer (or a court) can see why the system thinks two accounts are one person. A pipeline that outputs a confidence score without the evidence behind it is an unfalsifiable accusation generator, which is the opposite of what you want.

This is also where the prosecutor’s fallacy from Part I becomes operational: a pipeline runs across your whole population, so its false-positive rate is multiplied by a large denominator. Build the human-review gate, and the corroboration requirement, into the design — not as an afterthought.

Part V — Decloaking techniques (the defensive, lawful kind)

“Decloaking” — revealing an actor hiding behind anonymity — is the most misused term in this space, because the same words describe a lawful blue-team tool and an illegal privacy attack. The dividing line is simple and worth stating bluntly:

You may instrument data and systems you own. You may place a beacon in your own document and learn the IP of whoever opens it. You may not trick a person into running code that exploits their device, and you may not target the anonymity of an innocent person. The first is deception defense; the second is, depending on specifics, a CFAA violation, stalking, or both.

Canary tokens and honeytokens — the workhorse

A canary token is a tripwire embedded in something tempting: a Word, Excel, or PDF document, a fake AWS or Slack credential, a database row, a URL, a DNS name. When someone interacts with it — opens the decoy file, tries the fake key, hits the URL — it phones home and alerts you, typically with the source IP, user agent, and timestamp. The crucial property is that the token lives in your data; the actor brings it onto their machine by stealing it. Thinkst’s Canarytokens (canarytokens.org) is the well-known free service, and commercial deception platforms extend the idea into full decoy environments.

The technique has a distinguished lineage. The “canary trap,” used for decades to catch leakers, seeds uniquely-watermarked copies of a sensitive document to each suspect; when a copy surfaces externally, the watermark names the leaker. The modern data-breach version is the same idea: a Q1-2026_Financial_Restructuring.docx honeytoken on a file share alerts the instant an intruder opens it, and an alert originating outside your network proves exfiltration and hands you the holder's IP. Fake credentials committed to a repo catch the scrapers that harvest them. A tracking pixel hosted on infrastructure you control, embedded in a message you send, is the same concept for email. All of this is legitimate on your own data and communications, subject to disclosure where required. Using any of it to covertly track an uninvolved private individual is where it becomes harassment or an illegal privacy intrusion.

Device and browser fingerprinting (fraud-prevention context)

On platforms you operate, device fingerprinting links accounts that try to look independent. Signals — user-agent, screen and canvas or WebGL rendering, installed fonts, time zone, language, audio-stack quirks — combine into a fairly stable identifier. Libraries like FingerprintJS and anti-fraud platforms like SEON use this to catch one fraudster running fifty accounts, to flag a “new customer” whose device matches a charged-back order, and to detect emulators and proxies. This is among the most effective anti-fraud signals in existence, and it’s lawful on your own users — but it operates on your surface, within your users’ consent and privacy-law framework (GDPR and CCPA both bite here), not as a covert weapon against outsiders. Its limits are real, too: privacy-hardened browsers randomize the very signals fingerprinting depends on, so it degrades over time and should never be a sole basis for action against a user.

Behavioral and linkage correlation

Often the strongest decloaking signal is mundane correlation across data you already hold. Temporal patterns reveal a working time zone, and sleep gaps are remarkably identifying. Reused identifiers betray operators: the same username (run it through Sherlock across hundreds of platforms), the same avatar (reverse image search and ExifTool metadata), the same phone number, the same crypto wallet recurring across “different” scams. And operational mistakes are the great equalizer — the actor who logs in once without the VPN, reuses a personal email for a “business” scam, or pastes a real name into a profile. Most real-world deanonymization comes from the target’s own OPSEC failure, not from any technical wizardry on your part.

Part VI — Data, feeds, and tooling: the resource map

Threat-intelligence feeds (free and open)

abuse.ch (ThreatFox, URLhaus, MalwareBazaar, Feodo Tracker) — high-quality IOCs: malicious IPs, URLs, malware samples, and botnet C2s. Free and API-accessible.
AlienVault OTX (LevelBlue) — a large community “pulse” feed of IOCs; free API with a registered account.
MISP — an open-source platform to ingest, dedupe, score, and share threat intel across organizations and ISACs; ships with many feeds enabled by default.
Spamhaus — DNS-based blocklists for spam- and malware-associated IPs and domains; the email-security standard.
CISA Known Exploited Vulnerabilities (KEV) — the authoritative list of vulnerabilities under active exploitation, for prioritization.
PhishTank / OpenPhish — community and automated phishing-URL feeds.
Cisco Talos, IBM X-Force Exchange — reputation lookups for IPs, domains, and files.

A useful aggregation point is the community-maintained “Open-Source-Threat-Intel-Feeds” repositories on GitHub, which bundle many IP, URL, hash, and CVE feeds with no signup.

Make the indicators count: the Pyramid of Pain

David Bianco’s Pyramid of Pain is the mental model that turns a feed of indicators into strategy. It ranks indicators by how much it hurts an adversary when you burn them. Hash values and IP addresses sit at the bottom — trivial for an actor to change, so blocking them buys you minutes. Domain names cost a little more. Tools and, at the apex, tactics, techniques, and procedures are expensive for an adversary to alter, because they’d have to relearn how they operate. The lesson for attribution: chase the high-pyramid signals (behavioral patterns, reused tradecraft, stylometric habits) over the disposable low-pyramid ones, because the high ones are both harder to fake and more durable across an actor’s campaigns.

OSINT investigation tools

Maltego — graph-based link analysis, the standard for visually mapping relationships between people, emails, domains, IPs, and infrastructure. Community edition available.
SpiderFoot — automated recon across 200+ data sources; point it at a domain, IP, email, username, or phone and it pivots automatically.
Recon-ng — a modular, scriptable web-recon framework (CLI).
theHarvester — emails, subdomains, hosts, and URLs from public sources.
Sherlock — hunts a username across hundreds of platforms.
Shodan / Censys — search engines for internet-connected devices and certificates; core to infrastructure pivoting.
Intelligence X (IntelX) — searches breach data, leaks, and historical/dark-web material.
Have I Been Pwned — whether an email or account appears in known breaches.
ExifTool — metadata extraction from images and documents (geotags, device, software).
GHunt / PhoneInfoga — pivot Google accounts and phone numbers, respectively.
crt.sh — Certificate Transparency search for subdomain and sibling-domain discovery.
Hunchly — evidence-grade capture and logging of web investigations (chain of custody).

A practical caution echoed by professional OSINT teams: some of these are distributed only via GitHub, and running unvetted tooling on your investigation machine is itself an OPSEC and malware risk — sandbox accordingly, and never authenticate your real accounts on investigation infrastructure.

Datasets for building and validating stylometric models

The PAN @ CLEF shared-task corpora are the standard benchmark for authorship attribution and verification, with fresh editions most years and a strong emphasis on the open-set verification framing. The Google Code Jam solution corpora are the canonical dataset for code authorship research. And the Federalist Papers remain the classic teaching set for disputed-authorship methods — small enough to reason about by hand, which is exactly why it’s still used.

Part VII — Putting it together: an investigation arc

A composite, realistic workflow — no single real case, but representative of how the pieces chain, with confidence graded at each step:

Intake. A phishing email targets your finance team. You preserve the raw .eml, hash it, and log the time and time zone. (Evidence integrity established.)
Header analysis. The Received chain and a failing SPF/DKIM confirm spoofing; the earliest trustworthy hop and X-Originating-IP give a candidate IP. (High confidence the From is forged; medium confidence on the origin IP, since lower hops are spoofable.)
Enrichment. RDAP places the IP in a known bulletproof-hosting ASN; geolocation names one country, but the hosting/proxy flags say it's a relay, so location is unreliable. (High confidence it's hosted, not residential; low confidence on geography.)
Infrastructure pivot. The phishing domain’s cert (via crt.sh) shares a SAN with three other domains; passive DNS shows all four resolved to the same /24 last month; Shodan finds a matching favicon hash on a fifth. (High confidence these five are one campaign.)
Content linkage. The lure text matches — stylometrically and on an exact idiosyncratic misspelling — messages from two earlier BEC attempts in your archive. (Medium-high confidence it’s one operator; corroborated by the misspelling, which is a high-pyramid signal.)
Identity signals. The reply-to username appears, via Sherlock, on a forum where the same handle once posted a personal email — two years and one OPSEC slip ago. (A lead, weighed carefully, never published unilaterally.)
Deception, optional, on your own data. You seed a watermarked decoy invoice; if the actor re-engages and opens it, a canary token returns their real IP and user agent.
Handoff. You package the evidence — hashes, headers, IOC list, confidence-rated linkage analysis — and refer it to law enforcement and the relevant abuse contacts. Unmasking the human behind the relay requires legal process you don’t have; that’s the correct stopping point.

Notice that no single step names a person. The case is the aggregate, and the confidence labels travel with it.

Part VIII — Ethics, false positives, and knowing when to stop

Misattribution causes real harm. The named-the-wrong-person failure mode isn’t hypothetical; it ruins lives and exposes you to defamation liability. Combine that with the prosecutor’s fallacy from Part I — scan a big enough population and you will generate confident false matches — and the discipline writes itself: high confidence and independent corroboration before you attach a human name to anything, or you don’t attach it at all.

Privacy law binds you. GDPR, CCPA, the Electronic Communications Privacy Act, the Stored Communications Act, and wiretap statutes constrain what data you may collect, retain, and share — especially about the uninvolved third parties who get swept into any population-scale analysis. Stay passive and on your own turf: the legal and ethical safe zone is your data, public data, and lawfully obtained data, and the moment a technique requires touching the target’s systems, you stop and escalate to law enforcement.

Don’t become the threat. Tools like SpiderFoot, Sherlock, and Maltego are, as one surveillance researcher put it, indifferent to intent — the same kit serves a fraud investigator and a stalker. The difference is entirely in what you do with it and to whom. And document for handoff: build every investigation as if a prosecutor will read it and a defense attorney will cross-examine it. If it can’t survive that, it isn’t finished.

About the author

Brian Curry is an applied AI researcher and causal economist, and the founder of Vector1 Research. His work spans applied machine learning, causal inference, and the economics of automation and AI, including open-source causal-inference tooling and ongoing research into what he calls the Autonomy Economy. He founded and leads the KC AI Lab and writes regularly on applied AI, data science, and security at medium.com/@brian-curry-research. This piece approaches fraud attribution and defensive security through an applied-AI and data-science lens — treating attribution as a probabilistic, evidence-weighting problem rather than a purely operational one.