Why the first file deserves extra scrutiny.
OpenEFA® Signals Series | March 27, 2026
Trust is built through repetition. A sender who has exchanged dozens of plain-text messages with you over several months has established a pattern — a pattern that does not include file attachments. When that sender introduces an attachment for the first time, the context of the relationship has fundamentally changed. That change, regardless of who the sender is, deserves deeper inspection.
First-time attachment behavior is a deceptively simple signal with profound security implications. It captures a critical moment in any email relationship: the transition from conversation to file transfer. Attackers understand that this transition is where payloads are delivered, and many of the most sophisticated attacks are specifically designed to make that first attachment feel natural and expected.
One of the most effective attack strategies in email security is the long-game approach: build trust first, deliver the payload later. This pattern exploits a fundamental weakness in how both humans and traditional security systems evaluate risk.
The attack unfolds in stages:
The attacker sends several clean, innocuous messages. These might be introductions, meeting requests, industry questions, or follow-ups on legitimate topics. Every message passes every security check. There are no links, no attachments, no suspicious content. The sender's domain may be newly created but properly configured with SPF, DKIM, and DMARC. Over days or weeks, the sender becomes a recognized contact.
The communication continues. The attacker demonstrates knowledge of the recipient's industry, references real events or people, and maintains a consistent, professional tone. The recipient replies. A conversation develops. Email security systems observe a series of clean exchanges and may adjust their risk assessment downward — this sender has a track record of benign communication.
Once trust is established, the attacker introduces an attachment or link for the first time. "Here's the proposal we discussed." "I've attached the whitepaper I mentioned." "Take a look at this report — I think it's relevant to your project." The context feels natural. The recipient expects the file. The email client shows a message from a known, trusted sender.
This is the moment that first-time attachment detection is designed to catch.
Traditional email security evaluates each message in isolation or against global reputation databases. The attachment itself is scanned for known malware signatures, sandboxed for behavioral analysis, or checked against URL blocklists. These are necessary measures, but they have well-documented limitations:
None of these evasion techniques address the fundamental question: should this sender be sending files to this recipient at all? That is a contextual question that requires relationship history, not just content analysis.
OpenEFA maintains a detailed attachment profile for each sender-recipient relationship. This profile tracks not just whether attachments have been sent, but how they have been sent:
The first-time attachment signal is not a binary block. It is a contextual threshold that triggers elevated analysis. When OpenEFA detects a first-time attachment in a relationship, several things happen:
First-time attachment detection is particularly valuable for catching compromised internal accounts. When an attacker takes control of a legitimate mailbox, they gain the ability to send messages that pass all authentication checks. But their behavior with attachments often betrays them:
Many internal email relationships are purely conversational. Team members discuss projects, schedule meetings, and share updates without ever attaching files — they use shared drives, collaboration platforms, or project management tools instead. When an attacker compromises one of these accounts and sends an attachment, it represents a first-time behavior for that specific relationship, even though the account has been active for years.
An attacker operating a compromised account may send attachments to recipients who have never received files from that sender. The attacker doesn't know (and cannot easily discover) which relationships include file sharing and which don't. This mismatch between the attacker's actions and the account's behavioral history creates a detectable signal.
A sender from the marketing department who has shared PDFs and image files for months suddenly sends a macro-enabled Excel workbook. The sender is known, the relationship is established, and attachments are expected — but the type of attachment is a first. OpenEFA tracks file type history separately from attachment presence, catching this category of deviation even within otherwise normal attachment relationships.
Consider this situation:
Sender: An external consultant who has been exchanging emails with your engineering team for four months.
Established pattern: 3–5 messages per week, all plain text. Discussions about architecture decisions, timeline adjustments, and meeting coordination. No attachments have ever been sent in this relationship — shared documents are exchanged via the company's collaboration platform.
New message: "Hi team — attached is the updated architecture diagram we discussed on Friday's call. Let me know if you have questions."
The message includes a file named "Architecture_Update_v3.docm" (a macro-enabled Word document).
The message sounds perfectly natural. The reference to Friday's call adds contextual credibility. The filename is professional and relevant. A traditional gateway scans the attachment, finds no known malware signatures, and delivers the message.
But OpenEFA detects several signals:
.docm extension indicates a macro-enabled document. Architecture diagrams are typically shared as PDFs, images, or via specialized tools — not as Word documents with macros.The result: the message is flagged for additional review. The recipient is alerted that this is the first attachment received from this sender and that the file type is unusual for the relationship. A quick verification with the consultant reveals that their account was compromised — they never sent the file.
The same principle applies to embedded links. A sender who has never included a URL in their messages to a particular recipient and then introduces one is exhibiting first-time link behavior. This is especially significant because:
OpenEFA tracks link introduction with the same rigor as attachment introduction. A first-time link from a sender who has only sent plain text is a behavioral change that deserves the same elevated scrutiny as a first-time file.
First-time attachment behavior is most powerful when combined with other OpenEFA signals:
First-Time Attachment Behavior is part of the OpenEFA Signals framework — a set of behavioral and contextual patterns that reveal risk before it becomes an incident.
The core principle: trust should not transfer automatically from messages to files. A sender who has earned trust through months of clean communication has earned trust for the type of communication they have established. When the nature of the communication changes — when conversation becomes file transfer — that trust must be re-evaluated.
Traditional security asks: "Is this file dangerous?"
OpenEFA asks: "Should this sender be sending files in this relationship?"
The first question requires the system to detect the threat inside the file. The second question recognizes that the file's mere presence is a signal — one that provides early warning before the file is ever opened, before the macro is ever executed, and before the link is ever clicked. In email security, the most valuable detection happens before the payload activates. First-time attachment behavior makes that early detection possible.