KnowBe4 Phishing

KnowBe4 Phishing Simulation Management

Overview

KnowBe4 phishing simulations are the core mechanism for testing and improving an organization's resilience to social engineering attacks. Campaigns deliver simulated phishing emails to users and track their interactions -- whether they opened the email, clicked the link, submitted data on the landing page, reported it via the Phish Alert Button, or took no action. The phish-prone percentage is the key metric derived from these campaigns.

Anti-triggers

• A real phishing email that reached a user — every campaign, click, and "failure" here is a simulation the MSP sent on purpose. Genuine inbound phishing is detected by the mail-security vendor: proofpoint-tap, avanan-threats, or abnormal-security-threats.
• Finding, releasing, or pulling a message out of a mailbox — KnowBe4 never touches production mail flow. Use proofpoint-quarantine or avanan-quarantine to release, and proofpoint-forensics to remove delivered mail.
• "Phish Alert Button" reports as a threat-intake queue — this skill counts PAB reports as a pass/fail signal on a simulation; the real user-reported phishing triage queue is ironscales-incidents.
• Enrolling the users who failed into remedial training — the enrollment side is knowbe4-training.
• Organization-wide phish-prone percentage or department breakdowns — per-campaign results are here; rolled-up metrics and benchmarks are knowbe4-reporting.

Key Concepts

Campaign Lifecycle

CREATED ──> SCHEDULED ──> IN_PROGRESS ──> COMPLETED
                │                              │
                └──── CANCELLED                └──> ARCHIVED

• Created: Campaign configured but not yet scheduled
• Scheduled: Campaign queued for delivery at a specific date/time
• In Progress: Emails are being sent and interactions tracked
• Completed: Campaign delivery finished, final results available
• Cancelled: Campaign aborted before completion
• Archived: Completed campaign moved to archive

Security Test Types

Recipient Interaction States

Each recipient in a campaign progresses through trackable states:

Phish-Prone Percentage Calculation

The phish-prone percentage (PPP) is the primary metric for organizational risk:

function calculatePhishPronePercentage(campaign) {
  const totalDelivered = campaign.recipients.filter(r => r.delivered).length;
  const totalFailed = campaign.recipients.filter(r =>
    r.clicked || r.replied || r.attachmentOpened || r.macroEnabled || r.dataEntered
  ).length;

  if (totalDelivered === 0) return 0;
  return ((totalFailed / totalDelivered) * 100).toFixed(1);
}

Industry Benchmarks:

Field Reference

Campaign Fields

Phishing Security Test (PST) Fields

Recipient Fields

MCP Tools

There is no campaign-level recipient tool. Recipients hang off a Phishing Security Test, never off a campaign, so "who clicked in this campaign" is two steps: knowbe4_phishing_campaign_tests to get the campaign's PSTs, then knowbe4_phishing_security_test_recipients per PST. A recipient ID is only meaningful alongside the pst_id it came from — knowbe4_phishing_security_test_recipient requires both.

There is no phishing-template tool. Nothing in this plugin lists the template library or reads a single template's content, and no page/ per_page sweep will find one. Template selection is console work. Campaign and PST records name the template that was used, which is enough to compare how templates performed after the fact, but not to browse what is available before a send.

None of the list tools filter by status or date. Narrowing to "completed campaigns since March" means paginating and filtering client-side.

Common Workflows

Review Campaign Results

1. List campaigns to find the target campaign
2. Get campaign details for overview metrics
3. List security tests within the campaign
4. Get security test results for detailed interaction counts
5. List recipients to identify who clicked/failed
6. Calculate PPP from the results

Identify High-Risk Users

1. List completed campaigns from a date range
2. Get recipients who clicked or entered data across campaigns
3. Cross-reference with user profiles for repeat offenders
4. Generate report of users who failed multiple tests

Compare Campaign Performance Over Time

1. List all campaigns sorted by date
2. Get PPP for each campaign
3. Track trend -- PPP should decrease over time with training
4. Identify anomalies -- sudden PPP increase may indicate new attack vector or template difficulty

Post-Campaign Remediation

1. Get failed recipients from completed campaign
2. Enroll failed users in remedial training
3. Schedule follow-up test targeting the same users
4. Compare results to measure improvement

Error Handling

Common API Errors

Data Considerations

Best Practices

1. Vary templates -- Use different phishing scenarios to avoid pattern recognition
2. Spread delivery -- Send over days/weeks, not all at once, to avoid "water cooler effect"
3. Track trends, not individual tests -- Single campaigns can be noisy; look at 3-6 month trends
4. Combine with training -- Auto-enroll failed users in relevant training modules
5. Use realistic scenarios -- Match templates to actual threats your clients face
6. Baseline first -- Run an initial campaign before training to establish baseline PPP
7. Report to leadership -- Share PPP trends with management to justify security awareness investment
8. Test all levels -- Include executives and IT staff, not just general users
9. Respect local regulations -- Some regions have restrictions on simulated phishing
10. Set proper tracking duration -- Allow 72 hours minimum for accurate click data

Related Skills

• KnowBe4 Training - Training campaign management and enrollment
• KnowBe4 Users - User management and risk scores
• KnowBe4 Reporting - Security awareness metrics and dashboards
• KnowBe4 API Patterns - Authentication, pagination, and rate limits