Cyber Kill Chain for QA Engineers

The Cyber Kill Chain is a seven-stage framework for understanding how a targeted cyber intrusion progresses from initial research to the attacker's final objective. For QA engineers, its value is not in learning how to attack systems, but in learning how to think about attack paths, identify where preventive and detective controls should exist and design security tests that break the chain before an attacker reaches sensitive data or critical functionality.

What the Cyber Kill Chain is

The Cyber Kill Chain was introduced by Lockheed Martin as part of an intelligence-driven defence model for analysing targeted network intrusions. It breaks an intrusion into seven stages:

1. Reconnaissance ↓ 2. Weaponization ↓ 3. Delivery ↓ 4. Exploitation ↓ 5. Installation ↓ 6. Command & Control ↓ 7. Actions on Objectives

The defensive idea is simple: an adversary must successfully progress through enough of these stages to achieve the objective. If defenders detect, deny, disrupt or contain the activity at an earlier stage, the intrusion becomes much harder to complete.

Why this matters to QA engineers

Security teams often use the Kill Chain for detection and incident analysis, but it is also useful during quality engineering because it encourages testers to look beyond a single vulnerability.

Stage 1 — Reconnaissance

Reconnaissance is the information-gathering and planning phase. An adversary tries to understand the organisation, exposed systems, technologies, people and processes before choosing an attack path.

Passive vs active reconnaissance

Type	Description	Examples
Passive	Information is gathered without directly interacting with the target.	Public websites, search engines, social media, public records and technical metadata.
Active	The target is contacted or probed directly.	Service enumeration, banner inspection, port scanning or social-engineering contact.

What QA can learn from reconnaissance thinking

• What technical information does the public application reveal?
• Do error messages expose framework, database or internal-service details?
• Are internal hostnames visible in HTML, JavaScript or API responses?
• Are source maps unintentionally exposed in production?
• Do public API specifications include endpoints that should not be externally reachable?
• Does the application expose exact dependency versions unnecessarily?
• Are employee or administrator details exposed beyond business need?

Example QA checks

Response headers: - Remove unnecessary technology disclosure - Avoid internal hostnames - Verify debug headers are absent Error responses: - No stack traces - No database queries - No filesystem paths - No credentials or internal service URLs Frontend: - No secret keys in JavaScript bundles - No production source maps unless intentionally exposed - No hidden admin routes containing sensitive data

Stage 2 — Weaponization

Weaponization is the stage where information collected during reconnaissance is turned into an attack package or capability. In traditional malware-centric intrusions, this might combine an exploit with malicious code or tailor a social-engineering lure to the target.

From a defensive QA perspective, this stage highlights the importance of reducing opportunities for crafted input or malicious content to reach dangerous execution paths.

Relevant controls to verify

• Uploaded files are validated by type, size and expected structure.
• Macro-enabled or otherwise dangerous file types are handled according to policy.
• User-generated HTML and rich text are sanitised.
• Untrusted documents are processed in isolated services where appropriate.
• OAuth application permissions are constrained and reviewed.
• Dependencies and parsers handling external content are maintained and patched.
• Email and content-security controls are aligned with the application's threat model.

QA example: file-upload boundary

Feature: Upload invoice attachment Security tests: ✓ Accept documented file formats ✓ Reject executable formats ✓ Reject files larger than policy allows ✓ Ignore client-supplied MIME type when server validation disagrees ✓ Sanitize generated filenames ✓ Store uploaded content outside executable application paths ✓ Return safe validation errors

Stage 3 — Delivery

Delivery is how an attack reaches the target. Traditional examples include malicious email attachments, links, removable media or compromised websites. Modern attacks may also arrive through third-party integrations, software supply chains, shared collaboration platforms or compromised identities.

What QA should focus on

Delivery surface	QA / security questions
Email / messaging	Are untrusted links and attachments handled safely? Are security warnings preserved?
File upload	Can uploaded content reach an executable or publicly exposed location?
Third-party integration	Are inbound callbacks authenticated and signed?
Package / update pipeline	Are packages, artefacts and updates obtained from approved trusted sources?
Web content	Can untrusted content inject script, redirects or dangerous markup?
API	Can arbitrary payloads reach sensitive backend functionality?

Watering-hole concept

A watering-hole attack compromises a website frequently used by a specific target population so that victims encounter malicious content while visiting a normally trusted destination. For QA, the broader lesson is that trust in a familiar external domain is not enough: third-party scripts, redirects and embedded content remain external dependencies.

Stage 4 — Exploitation

Exploitation is where a vulnerability or unsafe behaviour is used to execute code, bypass a control or gain access. This may involve a known vulnerability, an unpatched dependency, an unknown vulnerability or an application-level weakness.

Common exploitation opportunities QA can help reduce

• Broken authentication and authorisation.
• Injection flaws.
• Unsafe deserialisation or parsing.
• Outdated vulnerable dependencies.
• File-upload execution paths.
• Cross-site scripting.
• Server-side request forgery.
• Privilege-escalation logic flaws.
• Misconfigured cloud or infrastructure permissions.

Security regression example

Scenario: Normal user attempts an administrator operation Request: DELETE /api/users/42 Expected: 403 Forbidden No user deleted No privilege change Security event logged where required

Zero-day vs known vulnerability

A known vulnerability has already been identified and usually has remediation guidance or a CVE record. A zero-day generally refers to a vulnerability for which defenders or the affected vendor have had little or no time to prepare a fix before exploitation becomes possible or begins.

Stage 5 — Installation and persistence

After gaining access, an attacker may try to preserve it. Persistence allows access to survive restarts, credential changes, patching or interruption of the original compromise path.

Persistence techniques vary by platform. Examples can include unauthorised services, startup entries, web shells, modified scheduled tasks or other changes that cause attacker-controlled code to execute again.

What defenders should be able to detect

• Unexpected services or scheduled tasks.
• New executable files in sensitive application directories.
• Changes to startup configuration.
• Unexpected application users or API credentials.
• Modified infrastructure-as-code or deployment manifests.
• Unapproved web application files.
• Unexpected changes to critical file timestamps or metadata.

Web shells

A web shell is malicious server-side code planted in a web-accessible environment to provide continuing remote interaction with a compromised server.

Timestomping

Timestomping is the manipulation of file timestamps to make malicious or newly modified files appear older or less suspicious.

QA and platform-integrity tests

Deployment validation: - Only approved application artefacts exist - Container image digest matches expected build - No unexpected startup process is present - Filesystem permissions match baseline - Service accounts are expected - Infrastructure manifests match version control - Immutable environments are recreated rather than manually patched

Stage 6 — Command & Control

Command and Control (C2) is the communication channel used by an attacker to interact with compromised systems, issue instructions or receive information.

Attackers often attempt to blend command traffic with normal protocols. HTTP/HTTPS and DNS can be attractive because legitimate systems use them extensively.

DNS tunnelling

DNS tunnelling abuses DNS queries or responses to carry data or commands that would normally use another communication channel.

Defensive indicators

• Regular outbound connections with unusual periodicity.
• Connections to newly observed or suspicious domains.
• Unexpected outbound traffic from servers that normally receive requests only.
• Long or unusual DNS labels.
• Repeated DNS requests with high entropy or uncommon record patterns.
• Applications communicating with destinations outside documented dependencies.

QA implications

Application and infrastructure tests can verify that services are restricted to the destinations they genuinely require.

Expected service dependencies: checkout-api → payments-api:443 → orders-db:5432 Unexpected: checkout-api → arbitrary public internet destinations Security requirement: Outbound traffic restricted by policy.

Stage 7 — Actions on Objectives

Actions on Objectives are the outcomes the attacker originally wanted. Depending on the campaign, objectives may include stealing information, manipulating data, disrupting services, gaining wider privileges or damaging recovery capabilities.

Examples of attacker objectives

• Credential theft.
• Sensitive-data collection.
• Data exfiltration.
• Privilege escalation.
• Lateral movement.
• Business-data alteration.
• Backup deletion or corruption.
• Service disruption.

Shadow copies

Microsoft Windows Volume Shadow Copy Service can create point-in-time copies or snapshots of files and volumes. Destructive attacks and ransomware frequently target recovery mechanisms because intact backups reduce attacker leverage.

QA test questions at this stage

• Can one compromised account export all customer data?
• Are bulk exports rate-limited, authorised and audited?
• Can application users delete backups or recovery data?
• Can one tenant access another tenant's resources?
• Can a low-privilege identity reach administration functions?
• Does destructive activity require additional approval?
• Can recovery be completed from an independent backup?

Breaking the Kill Chain

The value of the model is that defenders do not need to wait until the final stage. Security controls can interrupt activity at several points.

Stage	Prevent / reduce	Detect / verify
Reconnaissance	Minimise unnecessary public exposure.	Monitor unusual enumeration and probing where appropriate.
Weaponization	Secure content handling, patch parsers, restrict dangerous file types.	Scan suspicious content and analyse anomalous inputs.
Delivery	Filtering, attachment controls, signed integrations, safe browsing.	Monitor suspicious inbound content and redirects.
Exploitation	Patching, secure coding, least privilege, application controls.	EDR, application logs, WAF signals, anomaly detection.
Installation	Immutable infrastructure, restricted filesystem and service permissions.	File integrity monitoring, service/process monitoring.
Command & Control	Outbound restrictions, segmentation, DNS/web filtering.	Network analytics, DNS monitoring, beacon detection.
Actions on Objectives	Data access controls, segmentation, backup isolation, DLP.	Audit logs, unusual export detection, privileged-action monitoring.

Lockheed Martin's original defensive model also describes countermeasures in categories such as Detect, Deny, Disrupt, Degrade and Deceive. The important idea is to create multiple opportunities to stop the intrusion rather than depending on one perfect control.

Think in attack paths, not isolated bugs

A realistic security failure may require several weaknesses to combine.

Example attack path: Public application exposes framework version ↓ Known vulnerable component remains unpatched ↓ Application service account has excessive permissions ↓ Compromised service can reach internal database ↓ Database identity can read every tenant ↓ Bulk exports are not monitored Result: One technical vulnerability becomes a major data breach.

QA value

Traditional functional testing might report only the vulnerable component. Attack-path thinking asks whether compensating controls reduce the actual business impact.

Use the Kill Chain during threat modelling

For an important feature, walk through the chain from an adversary perspective without attempting exploitation.

Example: customer-document platform

Stage	Question
Reconnaissance	What does the public application reveal about storage, APIs and user identities?
Weaponization	What malicious document or input formats could target processing components?
Delivery	How can external documents enter the system?
Exploitation	What happens if a parser or upload validation fails?
Installation	Could a compromised process modify persistent application content?
C2	Can the processing service initiate arbitrary outbound connections?
Objectives	What sensitive customer documents could the compromised service access?

The resulting test plan should focus on the controls that meaningfully break this path.

Security testing ideas by stage

Kill Chain and detection engineering

Security testing should not only ask whether an attack is prevented. Some activity will eventually bypass prevention, so detection quality matters too.

For an important security event, verify:

• The event is logged.
• The log contains enough context to investigate.
• Secrets and unnecessary personal data are not logged.
• The event can be correlated with the user, service or request involved.
• High-severity behaviour generates an alert where required.
• The alert reaches the expected operational team.
• Repeated activity is visible rather than hidden by log sampling.
• Time synchronisation allows events across systems to be correlated.

Example

Security scenario: User attempts to access 100 customer records outside their tenant. Functional expectation: Every request is denied. Detection expectation: Repeated denied access is logged. Alert threshold triggers. Source identity and request IDs are recorded. No protected record content appears in logs.

Cyber Kill Chain vs MITRE ATT&CK

The Cyber Kill Chain and MITRE ATT&CK are complementary frameworks.

Cyber Kill Chain	MITRE ATT&CK
Seven high-level intrusion stages.	Detailed knowledge base of adversary behaviours.
Strong narrative for understanding attack progression.	Organises behaviours into tactics, techniques and sub-techniques.
Historically centred on targeted network intrusion.	Covers enterprise, cloud, mobile and industrial-control environments.
Good for explaining where the chain can be broken.	Good for mapping specific observed behaviours and defensive coverage.
Relatively simple.	Much more granular.

ATT&CK terminology

• Tactic: why the adversary is performing an action.
• Technique: how the adversary achieves the tactical goal.
• Sub-technique: a more specific implementation of a technique.
• Procedure: how a real adversary actually used the technique.

MITRE ATT&CK currently includes Enterprise tactics such as Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration and Impact, among others.

Limitations of the traditional Kill Chain

The traditional Cyber Kill Chain remains useful, but its simplicity introduces limitations.

1. Not every attack starts outside the perimeter

An insider already has authorised access. Insider threat therefore requires separate consideration rather than forcing every scenario into a perimeter-intrusion narrative.

2. Attacks are not always linear

An adversary may repeatedly perform discovery, credential access, privilege escalation and lateral movement across many systems.

3. Cloud and identity attacks may not fit neatly

An attacker using stolen cloud credentials may obtain significant access without delivering malware to a traditional endpoint.

4. Supply-chain compromise can bypass early stages

A trusted software component or service may deliver attacker-controlled behaviour directly into an environment.

5. The model is intentionally high-level

It does not provide the detailed technique catalogue or telemetry mappings available in frameworks such as MITRE ATT&CK.

For these reasons, do not use the Kill Chain as the only security model for a modern system.

Insider threats

Insider risk deserves separate consideration because an insider may begin with legitimate credentials and system knowledge.

QA questions

• Can privileged actions be performed without additional approval?
• Are duties appropriately separated?
• Are sensitive exports audited?
• Can support personnel access customer records without a documented reason?
• Does de-provisioning remove access quickly?
• Are inactive accounts disabled?
• Can service credentials be reused outside their intended workload?

Build a security coverage matrix

A simple matrix helps connect Kill Chain stages to concrete controls and automated checks.

Stage	Control	Automated QA evidence
Recon	Production error hardening	Responses never expose stack traces or internal paths.
Delivery	Upload validation	Unsafe file types and invalid payloads rejected.
Exploitation	Authorisation	Permission matrix tested through API.
Installation	Immutable deployment	Running image digest matches approved artefact.
C2	Network policy	Application cannot connect to unapproved destinations.
Objectives	Export restrictions	Bulk export requires correct role and is audited.

CI/CD applications

Some Kill Chain controls can be verified before deployment.

Pull Request │ ├─ Secret scanning ├─ Dependency scanning ├─ Static analysis ├─ Security unit/API tests ▼ Build artefact │ ├─ Image/package scanning ├─ Signature/provenance checks ▼ QA deployment │ ├─ Security smoke tests ├─ Authorisation matrix ├─ Upload/input tests ├─ Configuration checks ▼ Production │ ├─ Monitoring ├─ Audit logs ├─ Detection rules └─ Incident response

Common mistakes when using the Kill Chain

Mistake	Better approach
Assuming every attack follows all seven stages in order.	Use it as a model, not a literal event sequence.
Focusing only on malware.	Include identity, cloud, application and supply-chain attack paths.
Mapping a control to one stage and considering it complete.	Use defence in depth across multiple stages.
Only testing prevention.	Test detection, containment and recovery too.
Ignoring insider threats.	Model authorised-but-malicious and accidental insider scenarios separately.
Using IP/hash indicators as the whole defence strategy.	Also detect behaviour and technique patterns.
Confusing Kill Chain with ATT&CK.	Use Kill Chain for progression and ATT&CK for behavioural detail.
Reporting every weakness equally.	Prioritise the attack paths with the greatest likelihood and impact.

Cyber Kill Chain QA checklist

• The most valuable application assets are identified.
• Likely external and insider adversaries have been considered.
• Public information disclosure has been reviewed.
• Production errors do not reveal internal implementation details.
• External files and content are validated and isolated appropriately.
• Inbound integrations authenticate the sender.
• Known vulnerable dependencies are identified and managed.
• Authentication and authorisation are tested independently.
• Privilege boundaries are tested through direct API calls.
• Important attack paths contain more than one defensive control.
• Deployment artefacts are traceable to approved builds.
• Unexpected persistent configuration changes can be detected.
• Services have only the outbound connectivity they require.
• Important DNS and outbound network behaviour is observable.
• Bulk data access and exports are controlled and audited.
• Backups and recovery mechanisms are isolated from normal application permissions.
• High-risk destructive actions require appropriate controls.
• Security events contain enough context for investigation.
• Sensitive values are excluded from logs.
• Detection controls are tested as well as preventive controls.
• Insider scenarios are considered separately from external intrusion.
• MITRE ATT&CK is used when technique-level detail is needed.
• Kill Chain findings are prioritised using business risk.
• Security tests are integrated into CI/CD where practical.

Cyber Kill Chain cheat sheet

Stage	Attacker goal	Defender focus
Reconnaissance	Understand the target.	Reduce unnecessary exposure and detect probing.
Weaponization	Prepare an attack capability.	Harden content processing and reduce exploitable attack surface.
Delivery	Get malicious content or access to the target.	Filter and authenticate inbound content and integrations.
Exploitation	Use a weakness to gain execution or access.	Patch, validate, authorise and apply least privilege.
Installation	Preserve access.	Protect deployment integrity and detect unauthorised persistence.
Command & Control	Communicate with compromised systems.	Restrict and monitor outbound communication.
Actions on Objectives	Achieve the final goal.	Protect data, privileges, backups and business-critical operations.

Key takeaways

• The Cyber Kill Chain provides a simple seven-stage narrative for targeted intrusions.
• The defensive objective is to interrupt the attack as early and as often as possible.
• QA engineers can use the model to design security tests around exposure, input, authorisation, persistence, network controls and sensitive actions.
• Security coverage should include prevention, detection, containment and recovery.
• Attack paths are often more important than isolated vulnerabilities.
• Real attacks may skip, repeat or reorder Kill Chain stages.
• Insider, cloud, identity and supply-chain threats require additional models and threat thinking.
• MITRE ATT&CK complements the Kill Chain with detailed tactics, techniques, sub-techniques and real-world procedures.
• Security quality improves when Kill Chain thinking is incorporated into threat modelling, automated tests and CI/CD controls.

Useful links

• Lockheed Martin Cyber Kill Chain ↗ — official overview of the seven-stage framework.
• MITRE ATT&CK ↗ — adversary tactics and techniques based on real-world observations.
• Getting Started with MITRE ATT&CK ↗ — explanation of tactics, techniques, sub-techniques and procedures.
• CISA Insider Threat Mitigation ↗ — guidance on insider-risk concepts and mitigation.
• OWASP Top 10 ↗ — common web-application security risks.
• OWASP API Security ↗ — common security risks affecting APIs.