Unified Kill Chain for QA Engineers

The Unified Kill Chain (UKC) is an attack-lifecycle framework designed to model how modern cyber attacks progress from initial preparation to final objectives. Unlike simpler linear kill-chain models, the UKC uses 18 phases and explicitly recognises that attackers may loop, repeat phases, pivot between systems and move back and forth through an environment. For QA engineers, the framework is useful for threat modelling, security-focused test design and identifying where preventive, detective and recovery controls should interrupt an attack path.

What a kill chain represents

A kill chain describes the sequence of activities an adversary may perform to achieve a goal. In cybersecurity, the concept is used to decompose an intrusion into understandable phases so defenders can identify where an attack can be prevented, detected, disrupted or contained.

Understanding the chain is useful because a successful compromise rarely depends on one weakness alone. Attackers often need several conditions to line up: exposed services, weak authentication, excessive privileges, reachable internal systems and insufficient monitoring.

Threat modelling

Threat modelling is the structured process of identifying what must be protected, how it could be attacked and which controls reduce the resulting risk.

A practical threat-modelling flow

1. Identify assets. Applications, services, credentials, infrastructure, customer data and business processes.
2. Understand their role. Which assets are critical, internet-facing or sensitive?
3. Identify weaknesses and attack surfaces. APIs, identities, uploads, dependencies, network paths and configuration.
4. Model realistic attack paths. How could an attacker move from an exposed surface to a valuable asset?
5. Map controls. Prevention, detection, containment and recovery.
6. Test the controls. Verify that they work under expected and failure conditions.
7. Feed lessons back into design. Improve SDLC practices, architecture and security policy.

Introducing the Unified Kill Chain

The Unified Kill Chain was developed by Paul Pols to unify and extend ideas from earlier attack-lifecycle models and MITRE ATT&CK. The current official UKC contains 18 attack phases and groups them into three broad goals:

Current 18-phase model

Goal: In — Initial Foothold

The In goal represents the adversary's effort to establish initial access inside the target environment.

Reconnaissance

Reconnaissance gathers information about the target before or during an attack.

• Internet-facing systems and services.
• Employee names and contact details.
• Technology stacks and software versions.
• Potential credentials exposed publicly.
• Network topology and related systems.
• Business processes that could be abused through social engineering.

QA perspective

• Do production errors expose internal hostnames?
• Are debug endpoints reachable publicly?
• Are technology versions unnecessarily disclosed?
• Do frontend bundles contain internal API URLs or secrets?
• Are source maps intentionally exposed?

Resource Development

Resource Development covers preparatory activities required for the attack, such as creating infrastructure, accounts, domains or systems used later in the intrusion.

In older UKC material this phase was called Weaponization. The broader Resource Development term better reflects modern attacks where preparation may involve infrastructure, identities and services rather than only building malware.

Defensive questions

• Can newly created external integrations connect without approval?
• Are OAuth applications reviewed before receiving sensitive permissions?
• Are suspicious domains or external services observable in telemetry?
• Can untrusted infrastructure communicate freely with internal workloads?

Delivery

Delivery is the transmission of attacker-controlled content, access or payloads into the target environment.

• Email attachments and links.
• File uploads.
• Third-party integrations and callbacks.
• Compromised websites.
• Software supply chains.
• External APIs.

QA test examples

Social Engineering

Social Engineering describes manipulation of people into performing actions that aid the attack.

• Phishing.
• Credential-harvesting pages.
• Impersonating support personnel.
• Requesting an unauthorised password reset.
• Convincing a user to approve excessive OAuth permissions.

QA relevance

• Password resets require sufficient identity verification.
• High-risk account changes may require MFA or step-up authentication.
• Users receive clear information before granting permissions.
• Sensitive actions cannot be performed solely because a caller knows public account information.

Exploitation

Exploitation is the use of a vulnerability to obtain execution, access or another tactical advantage.

• Input validation.
• Authentication and authorisation.
• Dependency patching.
• Secure file handling.
• Injection testing.
• Privilege-boundary testing.
• Secure default configuration.

Example authorisation regression

Persistence

Persistence enables an attacker to retain access after the original compromise method disappears.

• Unexpected startup services are detected.
• Deployment artefacts are immutable.
• Infrastructure changes are version-controlled.
• New service accounts and credentials are audited.
• Unauthorised application files are detected.

Defense Evasion

Defense Evasion describes actions intended to bypass or avoid protective controls and detection.

• Endpoint protection.
• Web application firewalls.
• Network firewalls.
• Intrusion detection.
• Security logging.
• Application audit controls.

QA perspective

Command & Control

Command & Control (C2) is the channel through which an adversary communicates with systems under their control.

• Restrict outbound network access.
• Document legitimate service dependencies.
• Monitor unusual DNS and HTTP destinations.
• Use segmentation between workloads.
• Detect abnormal communication patterns.

Goal: Through — Network Propagation

Once initial access exists, the adversary may need additional permissions or systems before reaching the actual objective. The Through goal models this expansion through the internal environment.

Pivoting

Pivoting uses an already compromised system as an access path to systems that are not otherwise reachable.

• Can the public service connect to every internal system?
• Are internal APIs independently authenticated?
• Does network segmentation limit lateral access?
• Does the web-server identity have excessive database privileges?

Discovery

Discovery gathers information after access has already been obtained. The attacker may enumerate user and service accounts, permissions, software, files, shares, connected systems and security configuration.

This is effectively internal reconnaissance and may repeat every time the adversary reaches a new system.

Privilege Escalation

Privilege Escalation gives the adversary stronger permissions than the initial account or process had.

• Root or SYSTEM.
• Local administrator.
• Domain or tenant administrator.
• Application roles with sensitive functions.
• Cloud identities with broader permissions.

QA example: privilege boundary

Execution

Execution refers to attacker-controlled code running on a local or remote system. From a defensive standpoint, the focus is on preventing unsafe execution paths and detecting abnormal execution.

• Server-side command execution paths.
• Unsafe script or template evaluation.
• File uploads reaching executable locations.
• Scheduled jobs accepting untrusted commands.
• CI/CD pipeline inputs.

Credential Access

Credential Access is the acquisition or control of credentials that can be reused for additional access.

• Passwords never appear in application logs.
• Tokens are not exposed in URLs.
• Secrets are not returned to unauthorised callers.
• Credential rotation invalidates old credentials as intended.
• High-value credentials have limited scope.
• Service-account secrets differ between environments.

Lateral Movement

Lateral Movement occurs when an adversary uses access to one system to reach and control another.

• Can one compromised user access unrelated tenants?
• Can one microservice impersonate another?
• Do internal systems authenticate requests independently?
• Are service identities scoped to specific resources?
• Can one environment reach another environment directly?

Goal: Out — Actions on Objectives

The Out goal represents activity against the assets the adversary ultimately wanted to reach.

Collection

Collection is the gathering of information before it is used or removed.

• Databases.
• Files and shared drives.
• Browser data.
• Email.
• Application exports.
• Audio or video.

QA questions

• Can one account enumerate all customer records?
• Are exports permission-controlled?
• Are bulk-read operations rate-limited where appropriate?
• Are unusually large queries observable?

Exfiltration

Exfiltration is the removal of data from the target environment.

• Egress restrictions.
• Data Loss Prevention controls where appropriate.
• Export permissions.
• Monitoring unusual transfer volume.
• Audit logs for bulk downloads.

Example test

Impact

Impact covers actions intended to manipulate, interrupt or destroy systems or data. This phase maps directly to attacks against integrity and availability.

• Data encryption.
• Data deletion.
• Account lockout or removal.
• Service disruption.
• Defacement.
• Destructive configuration changes.

QA resilience scenarios

• Can deleted data be restored?
• Can a normal application identity delete backups?
• What happens if a database becomes unavailable?
• Does a failed transaction leave partial data?
• Can critical configuration changes be rolled back?

Objectives

Objectives represent the strategic outcome of the attack rather than a technical technique.

• Financial gain.
• Espionage.
• Reputational damage.
• Business disruption.
• Sabotage.
• Extortion.

Two technically similar compromises may have completely different business consequences depending on the attacker's objective and the asset involved.

The In → Through → Out model

Use the UKC to design security tests

For an important feature, walk through the UKC from the perspective of the asset you are protecting.

Example: customer billing platform

Map controls to multiple phases

UKC and MITRE ATT&CK

The Unified Kill Chain and MITRE ATT&CK complement each other.

A practical combination

Use UKC to understand where the attacker is in the attack path and ATT&CK to understand which concrete behaviours may be used.

UKC vs the traditional Cyber Kill Chain

A QA-focused security coverage matrix

Security testing in CI/CD

Not every UKC phase maps directly to an automated test, but the framework helps identify which controls deserve automated evidence and which need operational monitoring or specialist security validation.

Threat modelling with In, Through and Out

In

• What is publicly exposed?
• How can users or services authenticate?
• What external content enters the application?
• Which vulnerabilities could create initial access?

Through

• What can the initial identity reach?
• Can privileges be increased?
• Which credentials are accessible?
• Can one service reach unrelated systems?
• How large is the blast radius?

Out

• Which data is truly valuable?
• Can it be collected in bulk?
• Can it leave the environment?
• Can it be altered or destroyed?
• Can the organisation recover?

Common UKC mistakes

Unified Kill Chain QA checklist

• Critical assets and sensitive data are identified.
• Likely attack objectives are understood.
• The public attack surface has been reviewed.
• Production errors do not expose unnecessary technical details.
• External files and payloads are validated safely.
• Inbound callbacks and integrations authenticate the sender.
• Account-recovery and sensitive identity flows resist impersonation.
• Known application vulnerabilities are included in regression where appropriate.
• Authentication and authorisation are tested separately.
• Security events remain visible when operations are denied.
• Unexpected persistent changes can be detected.
• Public workloads cannot freely reach unrelated internal systems.
• Internal services authenticate and authorise independently.
• Role and privilege boundaries are tested directly.
• Passwords, tokens and secrets do not appear in logs or URLs.
• Service credentials follow least privilege.
• Users cannot enumerate data outside their scope.
• Bulk exports are controlled and audited.
• Outbound traffic is restricted where practical.
• Critical data can be restored after failure.
• Backups are protected from normal application identities.
• Detection controls are tested as well as preventive controls.
• UKC phases are mapped to actual system controls.
• MITRE ATT&CK is used when technique-level detail is required.
• Findings are prioritised according to business risk.

Unified Kill Chain cheat sheet

Key takeaways

• The Unified Kill Chain models modern attacks using 18 phases.
• The phases are grouped into the high-level goals In, Through and Out.
• Attackers can loop, repeat or bypass phases rather than following one deterministic sequence.
• Resource Development is the current name for the phase older material may call Weaponization.
• Impact is the current name for the phase previously called Target Manipulation.
• The UKC is particularly useful for modelling internal propagation after initial compromise.
• QA engineers can use it to identify security requirements and build risk-based security regression.
• Controls should be layered across several phases rather than relying on one choke point.
• MITRE ATT&CK complements UKC by adding detailed adversary techniques and sub-techniques.
• The ultimate objective is not framework compliance but improved resilience against realistic attack paths.

Useful links

• Unified Kill Chain ↗ — official Unified Kill Chain project and white paper.
• Unified Kill Chain White Paper ↗ — current 18-phase model by Paul Pols.
• MITRE ATT&CK ↗ — detailed adversary tactics, techniques and sub-techniques.
• MITRE ATT&CK Enterprise Matrix ↗ — current Enterprise tactics and techniques.
• OWASP Top 10 ↗ — common web application security risks.
• OWASP API Security ↗ — API-focused security risks and guidance.