【ITニュース解説】Wire Fraud in Real-Estate Closings: Forged Escrow and Title PDFs

不動産取引における電信送金詐欺は、住宅購入などの高額な資金移動を狙った深刻な問題だ。特に決済直前の送金指示書が偽造され、購入者が詐欺師の口座に資金を送金してしまうケースが多発している。これはビジネスメール詐欺（BEC）の一種であり、FBIの報告でも年間27億ドル以上の被害が確認されている。

典型的な詐欺の手口は、買い手が取引中に受け取っているメールのやり取りに巧妙に割り込むことから始まる。メールは正規の担当者からのように見え、件名や署名も偽装されている。添付されているPDFファイルは、タイトル会社のレターヘッドが入った正規の送金指示書に見えるが、実際には送金先の銀行口座番号が詐欺師のものに改ざんされている。買い手はこれを信じて指定された金額を送金してしまうが、後日、資金がタイトル会社に届いていないことが判明して初めて詐欺に気づくのだ。

これまでの詐欺対策は、主に「誰が、どのような手段で、何を要求しているか」を検証することに重点を置いてきた。例えば、メールとは別の電話回線で送金指示を再確認する「アウトオブバンドコールバック」や、安全な専用ポータルサイトの使用、送金における二段階認証などがある。しかし、詐欺師はこれらの対策を突破する手口を編み出しており、例えば、偽装した電話番号を使って確認の電話さえも欺くケースが報告されている。これらの対策は、要求内容やチャネルの正当性を検証するが、実際に送られてきたファイルの中身、特にPDFファイルが改ざんされていないかまでは検証できないという限界があった。

送金指示書の偽造には主に二つの手口がある。一つは「改ざんされたオリジナル」と呼ぶべき手口Aだ。これは、攻撃者が正規のメールボックスに不正アクセスし、タイトル会社が発行した本物の送金指示書PDFを入手する。その後、PDF編集ソフトを使って、送金先の口座番号やルーティング番号などの重要な情報だけを詐欺師の口座情報に書き換え、それを不正アクセスしたアカウントから、または偽装したメールアドレスで買い手に送り返す。この場合、文書自体は本物だが、一部が改ざんされている。もう一つは「偽造されたなりすまし」と呼ぶべき手口Bである。この手口では、攻撃者は本物の文書に一切触れない。代わりに、タイトル会社にそっくりなドメインを登録し、タイトル会社のロゴや書式を使って、送金指示書をゼロから作成し、正規の担当者になりすまして買い手に送る。この場合、文書自体が一から偽造されたものであり、改ざんされた痕跡は全く残らない。

本記事が焦点を当てるのは、手口Aのように「改ざんされたオリジナル」の文書が残す構造的な痕跡を検出する方法だ。タイトル会社が発行する正規の送金指示書は、通常、特定の決済システムや文書生成ソフトウェアによって作成される機関文書である。一度発行された後、編集のために再度システムに戻されることは想定されていない。そのため、もし発行後に一般的なPDF編集ソフトなどでファイルが開かれ、変更が加えられて保存された場合、そのPDFファイルには通常とは異なる構造的な情報が残る。

具体的な構造的痕跡としては、以下のような点が挙げられる。まず、PDFファイルに記録されている「作成ソフトウェア」の情報が、正規の決済プラットフォームのものではなく、一般的なデスクトップPDF編集ツールなどのものに変わっているか、あるいは元の情報に追加されている場合がある。次に、PDFが再保存されると、ファイル内に新たなリビジョンレイヤー（編集履歴の層）が追加される。正規に発行された文書には、通常このような複数のリビジョンレイヤーは存在しないはずだ。さらに、PDFファイルには作成日時と最終更新日時が内部的に記録されているが、もし最終更新日時が作成日時よりも後になっている場合、ファイルが作成後に何らかの変更を受けたと判断できる。デジタル署名が施されている文書であれば、署名後に内容が変更されると、署名と内容の不一致が記録される。また、ページ上の特定の数値やテキストが変更された場合も、その変更の痕跡がファイル構造に残ることがある。これらの痕跡は、オリジナルの文書がなくても、受け取ったPDFファイル自体を分析することで検出可能である。

このような構造的な痕跡を自動的に検出するためのAPIサービスも存在する。このAPIは、疑わしいPDFファイルのURLを受け取り、その構造を分析して、ファイルが改ざんされた可能性があるかどうかを教えてくれる。例えば、送金指示書の口座番号がデスクトップ編集ソフトで変更された後、転送されたケースでは、APIは「modified（変更された）」というステータスを返し、「日付の不一致」「編集ツールの痕跡」「複数のリビジョンレイヤー」「文字レベルの変更痕跡」といった具体的な変更の痕跡を示すマーカーと、「確実」であるという確信度を示す。

APIからの結果には、自動的な判断を避け、人間によるレビューを推奨する注意書きが含まれている。これは、APIの「modified」という結果が、あくまで「このPDFファイルが作成後に変更された」という事実を伝えるものであり、それが必ずしも悪意ある詐欺目的の変更であったり、送信者が犯罪者であると断定するものではないためだ。例えば、メールボックスが侵害された場合、送信者も被害者である可能性がある。したがって、ファイルが変更されていると判明した場合の正しい行動は、送金を一時停止し、攻撃者が関与できない別の安全なチャネルを使って、改めて情報を確認することである。

APIの結果が「inconclusive（不明確）」となる場合もある。これは、ファイルに構造的な変更履歴がないため整合性を確認できない状態を指す。日常的に使われるデスクトップソフトウェアで作成された多くの文書は、そもそも詳細な変更履歴を残さないため、このような結果になることは珍しくない。「inconclusive」が直ちに詐欺を示すものではないが、例えば、タイトル会社が発行するはずの文書が「inconclusive」である場合、通常はその種の文書は特定のシステムで発行され、一般的なデスクトップソフトでは作られないため、発行元に改めて正規のコピーを要求する理由となる。

ただし、この構造分析アプローチにも限界がある。前述の手口B、つまり「ゼロから偽造されたなりすまし」の送金指示書は、作成後に何も改ざんされていないため、構造分析では検出できない。この場合、ファイルは偽造されているにもかかわらず、「変更なし」と判断されてしまう可能性がある。また、このチェックは、送信者の身元が正規のものであるか、送金先の口座が実際にタイトル会社のものであるかの検証は行わない。これらは、本人確認サービスや口座確認サービスなど、別の目的を持つ機能が担うべき役割である。

したがって、このPDF構造分析は、不動産決済のワークフローにおいて、外部からシステムに取り込む文書、特に送金指示書や清算書、署名済み文書などに対して非常に有用だ。資金が移動する前や文書が正式に記録される前にこのチェックを実行し、その結果を記録しておくことで、監査や将来の紛争解決に役立てることができる。このチェックは、決済直前の極めて時間の制約がある状況で、買い手が不正な送金指示書に騙されるのを防ぐための重要な「層」となる。しかし、電話での再確認などの従来の対策が不要になるわけではない。むしろ、それらの対策を補完し、全体としてより堅牢なセキュリティ体制を構築するために、PDFファイルの構造分析をワークフローに組み込むことが推奨される。これにより、決済プロセスにおける特定の詐欺リスクを自動的かつ構造的に評価し、人間のレビューを必要とするケースを効果的に特定することが可能となるのだ。