Hack-Back

Plain-language definition

Leaving the defender's network to act directly against systems believed to be involved in an attack.

The definition is intentionally bounded. It identifies the property or role under discussion without converting terminology into a claim of deployment, recognition, personhood, citizenship, sovereignty, or authority.

Technical definition

Within the K01 knowledge model, Hack-Back is represented as a stable term object with code K01-TERM-134, canonical URL, claim status, topic owner, source links, related terms, last-reviewed date, research cutoff, and correction state. Relevant implementation components for the owning topic include least privilege; key lifecycle; immutable logs; build provenance; dependency controls; backups; failover; incident and correction records.

Legal or policy use

Security obligations vary by sector and jurisdiction; evidence must distinguish mandatory controls from recommended practice.

When a statute, regulation, standard, or external institution uses a different definition, that source-specific meaning controls the analysis of that source. The project definition is not silently substituted into current law.

What the term implies

The term implies that the stated property should be evaluated using the evidence appropriate to threat modeling, identity compromise, supply chain, monitoring, recovery, incident evidence and adversarial testing. It supports precise reference, comparison, data exchange, and correction across public prose and machine records.

What the term does not imply

Attribution can be wrong, intermediary infrastructure can be innocent, and private technical capability does not create legal permission.

It also does not convert a valid signature, credential, database record, model hash, or website into factual truth or legal authority without additional evidence and a competent decision.

Commonly confused terms

• Recovery
• Assistive Technology Evidence
• Release Evidence
• Autonomous Cyber Capability
• Active Cyber Defense
• Persistent Engagement

Confusion is resolved by asking which property is actually at issue: technical control, continuity, evidence, authority, legal recognition, operation, or normative status.

Operational test

1. Name the subject and purpose.
2. Identify the source definition and jurisdiction or technical context.
3. Collect evidence for the specific property.
4. Record currentness and limitations.
5. Route any governance, registry, assurance, or capital decision to the proper authority.

Related questions

• What is a reproducible build?
• Does an automated accessibility audit prove screen-reader usability?
• What evidence is required before a preemptive cyber operation?
• Does autonomous cyber defense create legal authority?
• How should autonomous security at nuclear infrastructure be evaluated?
• Does a Design Basis Threat authorize the use of force?

Sources

• NIST SP 800-218 Secure Software Development Framework Version 1.1 — NIST; SP 800-218 SSDF Version 1.1; Version 1.2 initial public draft tracked separately; Version 1.1 final; Version 1.2 initial public draft. Exact claim-support entries: 2. Revalidated 2026-08-14T22:04:09Z.
• NIST SP 800-53 Rev. 5, Release 5.2.0 Security and Privacy Controls — NIST; SP 800-53 Rev. 5, Release 5.2.0; Final control catalog with 2025 minor release. Exact claim-support entries: 2. Revalidated 2026-08-14T22:04:09Z.
• Supply-chain Levels for Software Artifacts (SLSA) Specification v1.2 — OpenSSF; SLSA v1.2; Approved. Exact claim-support entries: 2. Revalidated 2026-08-14T22:04:09Z.
• in-toto Attestation Framework — in-toto project; Current project framework; Open standard; CNCF graduated project. Exact claim-support entries: 1. Revalidated 2026-08-14T22:04:09Z.

Stable term code: K01-TERM-134. Last reviewed 2026-08-16.