Building a threat-actor case file: infrastructure clustering, alias pivoting, TTP fingerprinting, and honest attribution confidence.
Chapter 4 is about investigating an identity someone is willing to reveal, even partially. Threat actor profiling is a harder version of the same problem: the subject is actively trying to stay hidden, and often has real skill at it. This chapter is about building a case file on a malicious actor (a hacker, a fraud operator, an extremist organizer) from nothing but their infrastructure, their aliases, and the patterns in how they operate.
A profile is not a single fact. It is an accumulating case file with four parts that get built up over time, usually in this order: infrastructure (domains, IP ranges, hosting patterns the actor reuses), aliases (usernames, handles, and personas across platforms), tactics, techniques, and procedures (TTPs) (the specific methods the actor repeats across incidents), and a timeline tying all of the above to dated events. Each piece is weak evidence on its own. The profile's value comes from how many independent pieces point the same way.
Start every profile with a stated goal: are you trying to disrupt an ongoing campaign, attribute a past incident, or assess whether two incidents share the same actor? The goal changes which of the four parts you prioritize. Disruption favors infrastructure (get IPs and domains blocked fast). Attribution favors aliases and TTPs (build the identity case). Linking incidents favors TTPs alone (you don't need a name to say "this is the same actor as last time").
Chapter 9 covers WHOIS, DNS, and internet-wide scanning as general techniques. Applied to threat actor work, the goal is clustering: finding the set of domains, IPs, and certificates that all trace back to the same actor, even after they rotate individual pieces of infrastructure.
Underground and semi-underground actors are often careless once, and once is often enough. The technique that appears again and again in real unmasking cases is the same one from Chapter 4: find a single point where a persona used for the malicious activity leaked into an account, identifier, or platform the actor used for something more personal or older.
Common leak points, in roughly descending order of how often they show up in real cases: an old identifier (an early email, an ICQ or Skype number, a forum registration from years before the actor was careful) that ties a current handle back to an old, less-guarded profile; a reused avatar image, which reverse image search (Chapter 6) can trace to an earlier, more personal account; a distinctive writing style, in-joke, or recurring phrase that shows up on both the criminal-facing persona and a personal account; and boasting. Actors who feel untouchable frequently brag about their activity, sometimes under their real identity, on forums they don't expect investigators to read.
A well-documented pattern in public cybercrime-attribution write-ups: an actor's early, informal registration for one service (using a real or semi-real email or phone number) survives for years in some database or cached page, long after the actor has cleaned up their more recent activity. Investigators who patiently work backward through an alias's oldest footprint, rather than only its current one, repeatedly find this kind of leftover link.
Two incidents that look unrelated on the surface (different targets, different infrastructure, months apart) can still be the same actor if the underlying method matches closely enough. This is the logic behind frameworks like MITRE ATT&CK (already introduced in Chapter 3, §3.2, for search-based reconnaissance): cataloguing specific, repeatable techniques rather than surface details, so that a match on method carries real evidentiary weight even when every other detail differs.
Practical TTP fingerprints worth tracking: the specific phishing pretext or lure an actor reuses with only minor edits, a distinctive tool or script (even an off-the-shelf one) configured in a recognizable, non-default way, a consistent timing pattern (certain hours or days an actor operates, often revealing their time zone), and a consistent target-selection logic (the same industry, the same size of organization, the same geographic region every time). None of these alone proves a link. Together, across multiple incidents, they build a signature.
OSINT-based attribution is probabilistic, not conclusive, and the field has a real history of confident-sounding attributions that turned out to be wrong. Apply the same NATO Admiralty Code discipline from Chapter 2 explicitly: grade your source reliability and your information credibility separately, and state the resulting confidence level rather than presenting a name as a flat fact.
Three specific traps are worth naming. First, shared infrastructure and tools: criminal tooling is often bought, sold, or leaked, so two actors using the identical malware kit or the identical phishing template are not automatically the same actor. Second, false flag operations: a sophisticated actor can deliberately leave misleading artifacts (language strings, timestamps, tool choices) designed to point investigators toward a different actor or nation. Third, coincidental overlap: with enough incidents in a dataset, some will share superficial traits by chance alone. Weigh a profile's overall strength on the number of independent, hard-to-fake links, not on the total number of superficial similarities.
Threat actor profiling sits closer to the active-engagement end of the spectrum than most OSINT work in this manual, and it carries real consequences if done carelessly. A public, wrong attribution can be defamatory, can put an innocent person at risk of harassment or worse, and can tip off the real actor that they are being watched.
Keep four boundaries explicit. Passive infrastructure and alias research (WHOIS, passive DNS, public forum reading) is low-risk. Actively engaging an actor (posing as a buyer, joining their channel under a persona, baiting a response) is a meaningfully different, higher-risk activity that needs its own authorization and OPSEC plan (Chapter 16), not a casual extension of passive research. Never publish an attribution you would not be comfortable defending, in detail, to the person you are naming. And when profiling work uncovers something actionable (an active campaign, a real crime), the responsible next step is usually handing findings to the platform, a CERT, or law enforcement, rather than "exposing" the actor yourself.
For exercise 1, a shared certificate or identical hosting fingerprint across domains with unrelated-looking names is exactly the kind of "hard to fake" link this chapter is built around. If you find nothing, that's a legitimate negative result, not a failed exercise. For exercise 2, the oldest footprint is often on a service the person has forgotten still lists them: an early forum signup, an old code-hosting profile, an app that still has their original display name. For exercise 3, a strong answer names at least two independent categories of evidence (not two data points of the same type) and explicitly rules out shared-tooling and coincidence before reaching "probable."