Closing Table Takeover: How an Unverified Mortgage Contact Inserted Wire Fraud Into a Real Transaction

The wire instructions were embedded in a routine closing checklist. That is what makes this category of attack so effective: the fraud doesn't announce itself. It arrives dressed as coordination.

A title company received an email from a purported mortgage loan officer at a nationally recognized lender. The message referenced a specific loan number, a borrower name, and an estimated closing date of late June 2026. The body walked through a standard title requirements checklist (title commitment, deed, survey, flood certification) and noted outstanding items including wiring instructions and receipt of any earnest money deposit (EMD) checks or wires. The signature block carried the lender's corporate address and NMLS identifier, both of which matched publicly available company records.

There was no explicit demand to send funds. There was no hyperlinked credential page. The ask, at this stage, was simple: confirm receipt and provide an ETA on document return. This is the pretext phase of real estate business email compromise, establishing a trusted correspondent inside the workflow before the wire instruction pivot.

The Sender Identity That Couldn't Be Verified

The email arrived from an external address at ccm[.]com, a longstanding domain registered since 1993. WHOIS records showed the domain is registered through GoDaddy, but provided no public registrant contact. A public staff directory search for the named loan officer returned no results. A second named contact in the signature, another ccm[.]com address, also returned no verifiable public record.

Absence from a public staff directory is not conclusive. Large lenders don't always publish every loan officer. But a first-time external sender, no prior relationship with the title company, and a zero-result person search is precisely the combination that characterizes social engineering in the real estate closing lane. The attacker needs only to claim a plausible role ("loan officer," "processor," "closer") at a real institution, because the institution's credibility substitutes for the individual's verified identity.

Authentication told the same story at the final hop. The message transited through Mimecast, which performed its own DKIM and SPF checks and passed. ARC seals preserved those earlier attestations. But at the final delivery step, the originating IP (170.10.128.131) produced an SPF softfail, DKIM verification failed, and DMARC evaluated to fail under the sender domain's quarantine policy. The message also routed through hil1-relay[.]sendergen[.]com (51.81.185.125), an email signature management service, not a recognized security gateway. That relay's presence in the path, combined with the final-hop auth failures, means the authentication chain is unresolved: earlier hops vouched for a Mimecast scan; they did not vouch for the actual sending infrastructure's alignment with ccm[.]com.

MITRE ATT&CK T1566.001 covers spearphishing via attachment. T1656 (impersonation) applies to the loan officer persona and lender brand claim throughout the message. T1657 (financial theft) maps to the ultimate objective: diverting wire funds or EMD payments before closing.

The PDF Version-Swap Vector

The attachment set is where this attack's technical sophistication concentrates. Six PDF files accompanied the email, presenting as standard closing-package documents: multiple sales contracts, a borrower certification and authorization disclosure, an addendum, and a tax certificate.

Two of the sales contract files (Sales Contract.pdf and Sales Contract 3.pdf) shared identical page counts and file sizes but carried different MD5 hashes and different modification timestamps. Static analysis of both confirmed PDF version 1.7, no JavaScript, no OpenAction, no AcroForm. The technical risk in those two files is low. The process risk is the entire point.

Identical size, different hash means the content changed. In a closing document, the delta could be a single line: a bank account number, a routing number, a wire amount. Attackers use version proliferation to create enough confusion that title staff aren't certain which file is the authoritative one. A third similarly named file (Sales Contract Adden.pdf, with a typographical irregularity in the name, "Adden" rather than "Addendum") could not be fully sandboxed and could not be independently verified.

Both files also embedded a malformed local URI: file:/E:/https:/floridadep[.]gov/fgs/sinkholes. This is not a valid http/https address. It could be an authoring artifact from a document template that was improperly modified, or it could be an obfuscation attempt designed to confuse automated parser chains that expect well-formed URI schemes.

The two interactive files in the set warrant separate treatment. The Disclosure (Borrower's Certification and Authorization) contained an AcroForm with fillable signature fields and metadata referencing e-sign API endpoints at api[.]elliesign[.]com. No JavaScript was detected in that file. The Tax Certificate file, however, was flagged for both JavaScript and AcroForm elements. JavaScript inside a PDF form raises the possibility of client-side form submission or data exfiltration during a signing flow; without a deep object-level parse of the JavaScript action dictionaries, the behavior on interaction cannot be ruled benign.

See Your Risk: Calculate how many threats your SEG is missing

Why Closing-Workflow Pretexting Bypasses Gateway Defenses

The links in the email body were Mimecast-wrapped and scanned clean. The PDF files that did contain active content (JavaScript, AcroForms) didn't carry obvious external exfiltration endpoints in their static strings. The sender domain has a 30-year registration history. The NMLS number checked out. Nothing in this message matches the pattern of a blunt credential-harvest phishing email.

Real estate wire fraud pretexting wins at the gateway layer precisely because the content is plausible. The fraud is not in the email body. It's in what comes next if the title company responds. A reply that confirms the wiring file is ready, or that provides an ETA on EMD processing, establishes two-way communication. The next message in the thread is where attacker-controlled account details appear, and by then the thread has enough transactional context to look like a continuation of legitimate closing coordination.

IRONSCALES detected the behavioral profile: first-time external sender, identity unverifiable via public record, final-hop authentication failures, high-risk financial instructions in the body, multiple near-identical contract PDFs with hash mismatches, and interactive attachment elements warranting deeper inspection. The combination, not any single artifact, is what the detection surface needs to see.

Out-of-band verification remains the single most reliable control in this threat category. Any time a title or mortgage professional receives wiring or EMD instructions from a correspondent they have not previously verified, the verification call must use a number obtained from the lender's official public website or a pre-established contact record, never from the inbound email itself.

Indicators of Compromise