Stop Calling Them Hackers

We use hacker as if it were a verdict.

A hospital is hit by ransomware: hackers.

A government website is knocked offline: hackers.

A vulnerability researcher reports a flaw: hacker.

A teenager experiments with code: hacker.

A state intelligence unit steals diplomatic material: hackers.

A criminal crew runs credential phishing at scale: hackers.

A security team tests its own systems: hackers.

One word. Completely different actors, permissions, motives, capabilities and consequences.

That is not harmless shorthand.

It makes analysis worse.

---

"Hacker" describes too much to explain anything

The word has several real meanings.

In some technical communities, hacker is an identity associated with curiosity, experimentation and deep understanding of systems.

In vulnerability-disclosure and bug-bounty communities, companies openly work with people they call hackers or ethical hackers to find security weaknesses before criminals exploit them. HackerOne, for example, describes its community as security researchers who work with organizations to identify vulnerabilities.

In some security standards, the term is used more narrowly. NIST's current glossary includes a definition inherited from CNSSI material in which a hacker is an unauthorized user attempting to gain access to an information system.

These usages are not identical.

That ambiguity is exactly the problem.

If one word can describe both a researcher working inside an authorized bug-bounty scope and a criminal deploying ransomware, the word alone tells us almost nothing about the event.

---

Threat analysis needs actors, not costumes

Serious threat reporting already has better language.

NIST uses threat actor for an individual or group capable of causing harm.

ENISA's threat-landscape work distinguishes categories and motivations instead of treating every hostile cyber operation as one homogeneous phenomenon. Its recent reporting discusses hacktivists, cybercriminals and state-aligned actors separately because those distinctions change the threat model.

They matter operationally.

A financially motivated ransomware group may care about:

• payment;
• extortion;
• access brokers;
• scalable victim selection.

A state-linked intrusion set may prioritize:

• espionage;
• strategic access;
• persistence;
• geopolitical objectives.

A hacktivist group may prioritize:

• visibility;
• disruption;
• ideological messaging.

An authorized security researcher may be trying to:

• demonstrate a vulnerability;
• report it responsibly;
• earn a bounty;
• improve the target's security.

The technique can overlap.

The meaning does not.

---

Technique is not identity

This is where public reporting often breaks down.

Two people can use the same tool and belong to entirely different categories.

A port scanner can be used by:

• a system administrator;
• a penetration tester;
• a bug-bounty researcher;
• a criminal;
• a state operator.

A reverse shell is a technique.

Phishing is a technique.

Credential stuffing is a technique.

Exploit development is a capability.

None of those, by itself, tells you who the actor is or whether the activity was authorized.

When we collapse technique into identity, we stop asking the questions that matter:

Who acted?

Under what authorization?

Against what target?

With what objective?

Based on which evidence?

---

Authorization may be the most important missing word

Imagine two people discover the same vulnerability.

Person A finds it inside a published vulnerability-disclosure program, stays within scope and reports it.

Person B exploits it to steal customer data.

Technically, both may understand the vulnerability.

Socially, operationally and legally, they are doing very different things.

Calling both simply "hackers" removes the distinction that matters most.

Authorization is not a cosmetic detail.

It changes the event.

---

Motive matters too

Even among malicious actors, "hackers" hides useful information.

If an organization is attacked, defenders need to know whether the available evidence is more consistent with:

• financially motivated cybercrime;
• espionage;
• destructive activity;
• ideological disruption;
• insider activity;
• opportunistic exploitation.

Those hypotheses imply different:

• likely targets;
• persistence patterns;
• monetization paths;
• infrastructure;
• timelines;
• follow-up risks.

The label hacker contributes almost none of that analytical value.

---

Attribution is hard enough without lazy language

Cyber attribution is usually probabilistic.

Infrastructure is reused.

Tools leak.

Malware families are copied.

VPNs and hosting providers are shared.

One actor can imitate another.

A public statement may therefore support only:

activity is consistent with a known cluster

rather than:

actor X definitely performed the operation.

Using a vague label can make that uncertainty even worse.

"Hackers attacked the ministry" can sound precise while avoiding every difficult question:

• Which actor?
• What evidence?
• Which confidence?
• Which objective?
• Which campaign?
• Which time period?

Good language should expose uncertainty.

Not hide it.

---

The media problem is understandable

There is a reason the word survives.

"Hackers" is short.

Everyone recognizes it.

"Financially motivated threat actor using stolen credentials" is less elegant in a headline.

Precision has a cost.

But the solution is not to ban the word from human language.

The solution is to stop using it where the category matters.

A headline can remain readable:

Ransomware group disrupts hospital network

State-linked threat actor targeted diplomatic accounts

Hacktivists claimed responsibility for DDoS campaign

Security researcher disclosed authentication flaw

These descriptions are both clearer and more informative.

---

The security industry is inconsistent too

This is not only a journalism problem.

The cybersecurity field uses hacker in conflicting ways.

Bug-bounty companies celebrate hackers.

Training courses teach ethical hacking.

Standards may use the word for unauthorized users.

News reports use it for cybercriminals.

Popular culture uses it for almost anyone who can make a terminal look interesting.

We should not pretend there is one universally accepted definition.

There isn't.

That is why context must do more work.

---

A better vocabulary

When the evidence supports it, prefer the most specific accurate term available.

Use:

security researcher
when someone is investigating vulnerabilities in a research context.

authorized tester / penetration tester
when permission and scope are central.

bug-bounty researcher
when activity occurs inside a bounty program.

cybercriminal / financially motivated actor
when criminal financial motivation is supported.

ransomware group
when the operation is specifically ransomware/extortion.

hacktivist
when ideological motivation and the actor category are supported.

state-linked / state-nexus actor
when the attribution evidence supports that level of association.

threat actor
when you know the activity is hostile but the exact category remains uncertain.

unknown actor
when you genuinely do not know.

"Unknown actor" is not weak writing.

It is often excellent analytical discipline.

---

Do not replace one lazy label with another

There is a second trap.

Once we stop saying "hacker," it is tempting to overcorrect:

state-sponsored actor

organized cybercrime group

advanced persistent threat

These labels also require evidence.

Do not upgrade:

suspicious IP

into:

state actor

because the more precise phrase sounds professional.

Precision means using the narrowest label the evidence supports, not the most impressive label available.

---

Sometimes "hacker" is exactly the right word

There is a counterargument worth taking seriously.

People self-identify as hackers.

Security communities use the term positively.

Hacker culture has a long history that is larger than crime.

Erasing the word entirely would flatten that history too.

So the argument is not:

never say hacker.

It is:

do not use hacker as a universal synonym for malicious cyber actor.

If a researcher calls themselves a hacker, that can be accurate.

If a conference is a hacker conference, fine.

If a bug-bounty platform talks about its hacker community, the context is clear.

The problem begins when the word is asked to carry attribution, intent and authorization that it cannot actually establish.

---

Why this matters for OSINT

OSINT is largely a discipline of classification.

We take incomplete public observations and try to turn them into useful statements without overstating them.

Language is part of that process.

If our vocabulary collapses important distinctions, our database can be perfectly sourced and our conclusion can still be bad.

Consider the difference:

Hackers used infrastructure X.

versus:

Infrastructure X was reported by source Y as associated with a financially motivated ransomware cluster during period Z.

The second sentence preserves:

• source;
• actor class;
• uncertainty;
• time;
• relationship.

That is what an OSINT finding should do.

---

The rule

Before writing hacker, ask what you actually know.

Do you know:

• authorization?
• motive?
• actor class?
• campaign?
• attribution confidence?
• relationship to the observed activity?

If yes, use the better description.

If no, say:

unknown actor

or:

threat actor

when hostile intent is supported.

The language may feel less cinematic.

The analysis will be better.

---

References

Selected references for terminology and current threat-actor practice:

• NIST CSRC Glossary — Threat Actor
  https://csrc.nist.gov/glossary/term/threat_actor

• NIST CSRC Glossary — Hacker
  https://csrc.nist.gov/glossary/term/hacker

• NIST CSRC Glossary — terminology context and source caveats
  https://csrc.nist.gov/glossary

• ENISA — Threat Landscape 2025
  https://www.enisa.europa.eu/publications/enisa-threat-landscape-2025

• ENISA — Cybersecurity Threat Landscape Methodology
  https://www.enisa.europa.eu/publications/enisa-cybersecurity-threat-landscape-methodology

• HackerOne — Hacker Community / Security Researchers
  https://www.hackerone.com/platform/community