Weaponizing Trust: How to Detect Fake Incident Report Phishing Campaigns

Phishing remains the most prevalent initial access vector for a reason: it targets the human element, not just the technical. However, as highlighted in a recent SANS ISC diary, attackers are evolving their social engineering tactics to target specific professional mindsets.

The "love-hate" relationship security analysts have with reviewing phishing emails is well known—sifting through spam is tedious, but it is often where the most interesting Tactics, Techniques, and Procedures (TTPs) are revealed. One such trend is the use of Fake Incident Reports to lure victims.

Instead of a generic "Your password has expired," these emails pose as internal security alerts, incident reports, or critical notifications from your IT department. This psychological manipulation creates urgency and bypasses skepticism by mimicking authority.

The Threat Landscape

Why This Works

The "Fake Incident Report" attack is effective because it weaponizes trust and urgency. When an employee receives an email titled "URGENT: Security Incident Report - Action Required," their instinct is to comply to help the organization, especially if they are in a technical or administrative role.

Technical Analysis (TTPs)

While the source content was brief, our analysis of similar campaigns indicates a consistent pattern of TTPs:

1. The Lure: Emails typically originate from compromised external accounts or spoofed domains. The subject lines often utilize keywords like "Incident," "Breach," "Report," or "Ticket ID." The content usually suggests that a system the recipient manages is vulnerable or involved in an active breach.

2. The Payload: Rather than a malicious attachment (which is easily blocked by secure email gateways), modern campaigns often use HTML attachments that redirect to credential harvesting pages. Alternatively, they may include a link to a "view the full report," which leads to a fake Microsoft 365 or VPN login portal.

3. The Objective: The primary goal is Credential Harvesting. By convincing a sysadmin or SOC analyst that they need to log in to view a security report, attackers gain high-privilege credentials, allowing them to bypass perimeter defenses and move laterally.

Detection and Threat Hunting

To catch these campaigns before they result in a breach, security teams must move beyond basic signature detection. We need to hunt for the context of the email.

KQL Queries (Microsoft Sentinel / Defender)

Use these queries to hunt for suspicious emails mimicking incident reports.

Query 1: Hunt for emails with 'Incident' keywords from external domains

EmailEvents

| where Timestamp > ago(7d)
| where NetworkMessageId != "" // Ensure valid mail ID
| where Subject has_cs ("Incident", "Report", "Breach", "Security Alert")
| where SenderFromDomain !endswith "@yourdomain.com" // Replace with your internal domain
| project Timestamp, Subject, SenderFromAddress, RecipientEmailAddress, ActionType
| summarize count() by Subject, SenderFromAddress



**Query 2: Identify clicks on links within these emails**
EmailEvents

| where Subject has_cs ("Incident", "Report", "Breach")
| join kind=inner (EmailUrlInfo) on NetworkMessageId
| project Timestamp, Subject, RecipientEmailAddress, Url, ActionType
| where ActionType == "ClickAllowed"

PowerShell Script (Exchange Online)

If you are using Exchange Online, you can run the following snippet to investigate recent messages matching the "Incident Report" pattern.

# Connect to Exchange Online
Connect-ExchangeOnline

# Define the date range
$StartDate = (Get-Date).AddDays(-7)
$EndDate = Get-Date

# Define keywords associated with fake incident reports
$Keywords = @("Incident Report", "Security Breach", "Critical Alert", "Urgent Ticket")

# Build the search query (Search-Mailbox or Get-MessageTrace)
# Note: For large scale, use Compliance Search (New-ComplianceSearch)
$SubjectSearch = $Keywords -join ' OR '


Write-Host "Searching for emails matching subject criteria: $SubjectSearch"

Get-MessageTrace -StartDate $StartDate -EndDate $EndDate -SenderAddress NOT "*@yourdomain.com" | 
Where-Object { $_.Subject -match $SubjectSearch } | 
Select-Object Received, SenderAddress, RecipientAddress, Subject, Status | 
Format-Table -AutoSize

Python Script (Log Analysis)

This Python snippet can be used to analyze a exported log of email headers (JSON format) to identify spoofed headers or mismatched Reply-To paths often found in these attacks.

import 

# Simulating loading a log file (replace with actual file path)
# with open('email_logs.', 'r') as f:
#     logs = .load(f)

# Example data structure for demonstration
logs = [
    {"subject": "Incident Report #4920", "sender_domain": "external-security.com", "reply_to": "hacker@badsite.net"},
    {"subject": "Team Lunch", "sender_domain": "yourdomain.com", "reply_to": "admin@yourdomain.com"},
    {"subject": "URGENT: Security Breach Detected", "sender_domain": "notification-svc.net", "reply_to": "support@phish.io"}
]


def analyze_incident_phishing(logs):

    suspicious_keywords = ["incident", "breach", "report", "urgent"]
    
    for email in logs:
        subject = email.get('subject', '').lower()
        sender = email.get('sender_domain', '')
        reply_to = email.get('reply_to', '')
        
        # Check if subject triggers keywords AND reply-to domain mismatches sender
        if any(word in subject for word in suspicious_keywords):
            if sender.split('@')[-1] != reply_to.split('@')[-1]:
                print(f"[ALERT] Suspicious Reply-To mismatch found in: '{email['subject']}'")
                print(f"   Sender: {sender} -> Reply-To: {reply_to}")

analyze_incident_phishing(logs)

Mitigation Strategies

Detecting the attack is only half the battle. Here is how to harden your environment against these specific social engineering tactics:

1. External Tagging: Ensure your email gateway automatically appends a clear visual tag (e.g., [EXTERNAL]) to all emails originating from outside your organization. This immediately flags a fake "Internal Security Alert."

2. DMARC, SPF, and DKIM: Strictly enforce email authentication protocols. While spoofing is common, many of these campaigns rely on lookalike domains or compromised accounts. Rejecting mail that fails DMARC validation stops the low-hanging fruit.

3. Conditional Access (Context-Aware): Implement Conditional Access policies that require MFA specifically when a login attempt comes from an unfamiliar device or location, particularly if triggered shortly after receiving an email.

4. User Reporting: Empower your users. If a phishing email reaches the inbox, the "Report Phishing" button is your fastest route to quarantine. Train your IT staff specifically on this vector—tech-savvy users are often the most confident and thus the most vulnerable to technical-sounding scams.

Conclusion

The "Fake Incident Report" campaign is a reminder that attackers study our operations. By mimicking the very tools and alerts we use to stay safe, they try to trick us into opening the door. Stay vigilant, trust but verify (via the [EXTERNAL] tag), and keep hunting.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub