Full Report
Hayden Covington // Phishing is an ever-present threat, but lately, user education and spam filters have helped mitigate some of that threat. But what happens when a phish makes it […] The post Stop Phishing Yourself: How Auto-Forwarding and Exchange Contacts Can Stab You in the Back appeared first on Black Hills Information Security, Inc..
Analysis Summary
# Best Practices: Preventing Email Phishing Escalation via Ticketing System Forwarding
## Overview
These practices address the specific risk where emails classified as phishing internally (IntraOrgPhish) are forwarded to external or integrated systems (like Jira) via user distribution lists or contacts, bypassing inbound email security controls and effectively "phishing" internal users through a seemingly trusted platform (the ticketing system).
## Key Recommendations
### Immediate Actions
1. **Investigate Existing Forwarding Rules:** Immediately review all email distribution lists, shared mailboxes, and contacts configured to forward emails to integrated systems (e.g., Jira, ServiceNow, ticketing platforms).
2. **Audit O365 Logs for Forwarded Phishing:** Run targeted searches in O365/M365 logs for mail marked as `“Phish”` with `DeliveryAction: Delivered` or an `Outbound Spam` classification, specifically checking if the recipient was an integrated system alias or service account.
3. **Isolate or Disable High-Risk Forwarding Contacts:** Temporarily disable or place under restrictive review any Exchange Contact acting as a forwarding intermediary to ticketing systems until the connection method is validated as secure.
### Short-term Improvements (1-3 months)
1. **Convert Forwarding to Polling/API Integration:** Migrate email ingestion methods for ticketing systems from reliance on inbound email forwarding (where the P1Sender and P2Sender are manipulated during transit) to secure polling or API integration methods (e.g., using established service accounts).
2. **Implement Intra-Organizational Phishing Policy Review:** Ensure that the O365/M365 inbound policy for **IntraOrgPhish** is configured to **Block and Quarantine**, rather than relying on user action or softer filtering, especially for emails spoofing internal addresses.
3. **Develop Detection for Outbound Phishing:** Create specific detection rules (e.g., using SIEM or M365 Defender) to alert when emails classified as phishing internally are subsequently sent out or forwarded to known external integration endpoints.
### Long-term Strategy (3+ months)
1. **Establish Whitelisting/Exception Review Process:** Document and apply strict governance over any necessary exceptions that prevent internal phishing from being blocked (e.g., marketing service emails). Ensure exceptions do not bypass necessary quarantining.
2. **Integrate Attachment Scanning into Ticketing Workflow:** Implement controls within the ticketing system (if possible) to scan attachments delivered via ingestion hooks (API or polling) against threat intelligence feeds or sandbox environments before they are viewable by end-users.
3. **Conduct Targeted User Awareness Training:** Implement training that specifically addresses the context of danger—reminding users that attachments within internal tickets, documents, or project management tools can pose the same risk as attachments in direct emails.
## Implementation Guidance
### For Small Organizations
- **Focus on Log Review:** Prioritize actively monitoring O365 security audit logs for combinations of `IntraOrgPhish` or `Phish` verdicts combined with `Delivered` actions targeting known integration mailboxes.
- **Manual Remediation:** If integration setup is simple, manually change the ingestion method from forwarding to using a dedicated service account that connects via API/pull mechanism to the ticketing system.
### For Medium Organizations
- **Service Account Implementation:** Deploy dedicated, non-privileged service accounts specifically for email ingestion into ticketing systems (like Jira Service Management) using the recommended connection method (pull/API) rather than email forwarding contacts.
- **Policy Hardening:** Review and tighten Exchange Online Protection (EOP) or Defender for Office 365 policies to ensure any identified internal spoofing or phishing results in immediate quarantine, regardless of the sender/recipient path that triggers the classification.
### For Large Enterprises
- **Automated Workflow Remediation:** Develop and deploy automated responses using tools like Microsoft Sentinel or Logic Apps to flag or delete tickets/work items created via an email ingestion method if the source email contained malicious indicators (e.g., known bad attachments or URLs identified during initial classification).
- **Zero Trust for Integrations:** Treat all data pulled/forwarded into integration platforms with high scrutiny. Mandate that all such ingestion points use least-privilege service principals/accounts and established, non-forwarding connectivity methods.
## Configuration Examples
**O365 Audit Query Snippet (For Investigation)**
kql
O365.Audit
| where Timestamp > ago(7d)
| where o365.audit.Verdict == "Phish"
// Target emails that were delivered internally but should have been blocked
| where o365.audit.DeliveryAction == "Delivered" or o365.audit.DeliveryAction == "DeliveredAsSpam"
// Filter for potential internal spoofing leading to intra-org classification
| where o365.audit.Policy == "IntraOrgPhish" or o365.audit.Policy contains "Spoof"
**Jira Ingestion Method Recommendation (General Guidance)**
Migrate from: *User A forwards email to [email protected] $\rightarrow$ Jira issues are created.*
To: *Service account connects directly to Jira API using a dedicated channel/mailbox to pull support requests.* (Reference Atlassian documentation for adding an email account via approved methods.)
## Compliance Alignment
- **NIST SP 800-53 (AC-3, SI-4):** Focuses on boundary protection and system monitoring, ensuring that internal processes do not create new attack vectors when interacting with external/integrated services.
- **ISO/IEC 27002:2022 (A.8.22):** Addresses the management of information transfer and ensuring that security controls remain effective across system boundaries.
- **CIS Critical Security Controls v8 (Control 14):** Emphasizes secure configuration and management of software, specifically addressing the need to secure inter-system communication pathways.
## Common Pitfalls to Avoid
1. **Assuming "Internal" Means Safe:** Believing that an email classified as *IntraOrgPhish* automatically means the subsequent transfer channel (like a Jira forward) is safe or will inherit the original blocking action.
2. **Over-relying on SPF/DKIM for Internal Spoofing:** While external spoofing is covered, internal forwarding often breaks SPF checks, but the core risk here is the manipulation of *From* headers (P2Sender) that causes the internal classification.
3. **Not Auditing Outbound System Logs:** Only checking inbound email logs. The key failure occurred when the system logged the transfer as *Outbound Spam* instead of retaining the *Phishing* verdict.
## Resources
- **O365 Security Center Documentation:** Official guides for configuring Malware and Anti-Phishing policies (Defender for Office 365).
- **Atlassian Documentation:** Guides on correctly setting up email ingestion for Jira Service Management using dedicated polling accounts rather than simple email forwarding contacts. (Defanged Link Example: `https://support.atlassian.com/jira-service-management-cloud/docs/add-an-email-account/`)