How to combine a pentest with a phishing campaign

Running a penetration test alongside a phishing campaign is one of the most realistic ways to assess your organisation’s security posture. Instead of treating these two exercises as separate engagements, combining them creates a continuous attack chain that mirrors how real threat actors operate. The phishing campaign surfaces human vulnerabilities and delivers initial access, while the pentest exploits that foothold to show how far an attacker could actually go. Done well, the combined exercise gives you a far richer picture of risk than either test could produce alone.

This guide walks you through exactly how to structure and execute a combined engagement, from preparation through to documentation. Follow each step in order and you will end up with actionable findings that cover both your technical defences and your people.

What you need before combining both tests

Before anything else, confirm that you have the right authorisations, people, and tooling in place. A combined engagement is more complex than a standalone pentest or a single phishing simulation, so gaps in preparation will create problems mid-exercise that are hard to recover from.

• Written authorisation covering both the phishing campaign and the technical penetration testing scope, signed by an appropriate stakeholder
• A defined testing window that gives enough time for phishing results to feed into the pentest without rushing either phase
• A red team or testing lead who can coordinate both workstreams, since the two exercises need to stay in sync
• Phishing infrastructure including a sending domain, a credential-capture page or payload delivery mechanism, and tracking capability
• Pentest tooling appropriate to the agreed scope (network, application, Active Directory, cloud, or a combination)
• A communication plan that defines who on the blue team knows the exercise is happening, and who does not

Confirm that your legal and HR teams have reviewed the phishing component specifically. Simulated phishing that targets employees requires careful handling, particularly around how results are communicated internally after the exercise. Once these foundations are in place, you are ready to align the two tests strategically.

Align your pentest scope with phishing objectives

Define what you want the phishing campaign to achieve in the context of the pentest, not as a standalone awareness exercise. The phishing campaign is your initial access vector, so the pentest scope should be built around what happens after that access is obtained.

1. Identify the target outcomes of the pentest: lateral movement, domain compromise, data exfiltration, or access to a specific system or dataset.
2. Work backwards from those outcomes to determine what initial access would make them achievable. For example, if the goal is domain admin access, you need a phishing pretext that is likely to land in a user account with network connectivity.
3. Select phishing pretexts and lures that are plausible for your target organisation and aligned with the access level you need. A credential-harvesting lure targeting standard users is different from a payload-delivery lure targeting finance or IT staff.
4. Define the rules of engagement clearly: what happens if the phishing campaign fails to deliver access? Agree in advance whether the pentest proceeds with a simulated foothold or pauses.

You should end this step with a written scope document that maps phishing objectives directly to pentest objectives. Both workstreams should reference this document throughout the engagement so the two exercises remain connected rather than drifting apart.

Run the phishing campaign as your initial access vector

Launch the phishing campaign first and treat it as phase one of a single engagement rather than a separate exercise. Your goal here is to gain a foothold that the pentest team can then use to progress the attack chain.

1. Send phishing emails to the agreed target list using your prepared infrastructure. Keep the sending volume realistic and stagger delivery to avoid triggering bulk-send detection.
2. Monitor results in near real time: track opens, link clicks, credential submissions, and payload executions as they happen.
3. When a user interacts with the lure in a way that would grant access (credential submission, macro execution, or similar), record the timestamp, the target account, and the access type obtained.
4. If you are using a payload rather than credential harvesting, confirm that your callback or beacon is live and stable before handing the foothold to the pentest team.

At the end of this phase, you should have at least one confirmed foothold with documented access details. If multiple users interacted with the lure, prioritise the accounts that offer the most useful starting point for the pentest, typically those with broader network access or elevated permissions. With your initial access confirmed, the pentest team can begin its work.

Pivot from phishing results into the pentest

Hand off the phishing results to the pentest team with enough context for them to pick up the attack chain seamlessly. This pivot is the most technically demanding part of the combined engagement and where coordination matters most.

Assess what the foothold gives you

Start by enumerating the access obtained through the phishing campaign. Identify the compromised account’s permissions, group memberships, and network position. This tells you which pentest techniques are viable from this starting point and which are not.

1. Run privilege enumeration against the compromised account to understand what it can access directly.
2. Map the network segments reachable from the foothold, including any internal systems, file shares, or management interfaces.
3. Identify paths to privilege escalation, lateral movement, or persistence that are available from this position.

Execute pentest techniques from the foothold

With the enumeration complete, proceed with your pentest methodology using the phishing-derived access as your starting point. Common next steps include credential dumping, Kerberoasting, pass-the-hash attacks, or exploiting misconfigured services, depending on the environment and the agreed scope.

Document every action taken and every system accessed as you go. In a combined engagement, the audit trail needs to show clearly which findings originated from the phishing phase and which came from subsequent technical exploitation. This distinction matters when you present findings to the organisation.

Document findings across both workstreams

Bring the phishing results and the pentest findings together into a single, unified report rather than two separate documents. The power of a combined engagement is the attack chain it reveals, and that chain only becomes visible when the findings are presented together.

1. Structure the report around the attack chain: initial access via phishing, lateral movement, privilege escalation, and impact. Each section should reference specific evidence from the exercise.
2. For each finding, document the severity, the evidence, the business impact, and a concrete remediation recommendation. Avoid vague guidance like “improve security awareness” and instead specify what control or configuration change would have broken the attack chain at that point.
3. Include a phishing-specific section that covers open rates, click rates, credential submission rates, and payload execution rates. Contextualise these numbers against the pretexts used so the organisation understands what drove the results.
4. Map findings to a recognised framework such as MITRE ATT&CK to give the organisation a common language for prioritising remediation.

A well-structured combined report demonstrates not just that vulnerabilities exist, but how they connect into a realistic attack path. That narrative is what motivates remediation action. If you want support designing or running a combined engagement for your organisation, get in touch with us and we can scope an exercise that fits your environment and risk profile.