Phishing Module¶

The Phishing module enables users to report suspicious emails directly from Outlook via the PolicyClue add-in. Reported emails are stored as attachments on alerts and can optionally be analyzed by an automated sandbox.

Reporting an Email¶

When the Outlook add-in is deployed, users see a Report Email button in the Outlook ribbon. The button placement depends on the manifest type:

Exchange Online (Standard): The button appears in Outlook's dedicated Report section of the ribbon. Clicking it opens a small dialog that briefly explains the difference between phishing (malicious - analyzed and removed) and spam (unwanted but not harmful - just removed). By default the email is treated as phishing and analyzed; the user can override that with two optional checkboxes:
- I don't think this email is malicious - it's just annoying spam (no phishing)
- Email me the result when our security team has reviewed this (only for phishing)
A short text box at the bottom lets the user optionally explain what made the email suspicious - a sentence or two like "the sender domain looked off". This comment is shown to the security team during triage. - Exchange On-Premises (Legacy): Two separate buttons appear in the ribbon - Report Phishing and Report & Get Feedback. Spam reporting is not available on the legacy ribbon.

Clicking the report button:

Retrieves the complete email as an EML file (headers, body, and all attachments)
Sends it to the PolicyClue API as either a phishing_reported or spam_reported alert
Deletes the email from the user's inbox (soft delete to Deleted Items)

No Graph API access or Entra app registration is required for the Outlook add-in reporting feature.

When the user ticks the Email me the result checkbox (and leaves the spam box unchecked, so it is treated as phishing), the alert is flagged for follow-up. Administrators send a verdict reply from the Triage page; if the verdict is not phishing, the original email is attached to the reply so the user can read it again. Spam reports never request follow-up by design - checking the spam box overrides any notify request.

Overview Dashboard¶

The Overview page (Phishing > Overview) provides analytics on user reporting activity. Totals include both phishing and spam reports so admins can see overall reporting volume:

KPI cards: total reports, unique reporters, unique reported senders
Timeline chart showing report volume over time
Top reporters and top reported senders
Activity table with recent reports

Triage¶

The Triage page (Phishing > Triage) provides a dedicated workflow for reviewing open phishing reports. Spam reports are not shown here - they are removed from the user's inbox and counted in the Overview dashboard, but they don't require admin review.

Left panel: Scrollable list of open phishing reports showing subject, sender, reporter, and risk score. Reports with pending sandbox analysis are highlighted.
Right panel: Selected report detail with email metadata, the user's reason / comment, risk assessment, attachments with risk scores and tags, and triage action buttons.

Risk Assessment¶

Based on the sandbox analysis risk score (0-10):

Likely Phishing (score > 7): Red indicator
Suspicious (score 3-7): Amber indicator
Likely Safe (score ≤ 3): Green indicator
Pending Analysis (no score yet): Gray indicator with spinner

Triage Actions¶

For reports where the user requested feedback: - Not Phishing - Reply to User: Closes the alert, sets outcome to false positive, and sends a feedback email to the reporter with the original email attached - Confirmed Phishing - Reply to User: Closes the alert, sets outcome to true positive, and sends a confirmation email to the reporter

For reports without feedback requested: - Close as Safe / Confirm as Phishing: Same actions without sending an email

Outcome¶

The triage verdict is stored as event.outcome (ECS field) on the alert: - success - True positive (confirmed phishing) - failure - False positive (not phishing)

This field is also available in the general alert inspector for any alert type.

Alert Types¶

Alert Type	Description
`phishing_reported`	A user reported an email as phishing via the Outlook add-in. Analyzed by the sandbox; appears in the Triage queue.
`spam_reported`	A user reported an email as spam via the Outlook add-in. Removed from the inbox; not analyzed by the sandbox; not shown in Triage but counted in the Overview dashboard.

Attachments¶

Each phishing report includes the complete email and its extracted parts:

Reported email: reported_email.eml (message/rfc822) - the full original email including headers, body, and all attachments
Extracted parts: The sandbox worker automatically extracts the EML into individual parts (email body, file attachments) and adds them as separate attachments on the alert for independent scanning and URL extraction
Risk Score: null (pending) until analyzed by the sandbox, then 0-10

Attachment files are stored on disk as AES-256 encrypted ZIP archives in the attachments-data Docker volume. Only metadata (name, type, size, risk score) is stored in Elasticsearch. Attachments are visible in the alert inspector with a download button.

Sandbox Integration¶

When configured, a background worker (scan_attachments) automatically submits unscanned attachments to a sandbox instance for malware analysis. For EML files, the worker extracts the email body and embedded attachments, saves them as separate attachments on the alert, and scans each one individually in the next cycle. URLs found in HTML email bodies are also extracted and submitted to the sandbox.

Configuration¶

Set the following environment variables in the Docker Compose .env file:

Variable	Description
`CAPE_API_URL`	Base URL of the sandbox instance (e.g. `http://sandbox:8000`)
`CAPE_API_TOKEN`	API authentication token

Risk Scoring¶

The worker extracts the malscore from the sandbox analysis report and stores it as the attachment's risk_score (0-10 scale). The alert inspector displays risk scores with color-coded badges:

0-3: Green (low risk)
3-7: Yellow (medium risk)
7-10: Red (high risk)
Pending: Grey (not yet analyzed)

Webhook Integration¶

Alert payloads (including attachments) are automatically sent to configured webhooks. This allows integration with external SIEM, ticketing, or SOC tools. See Webhooks for configuration details.