カテゴリー: メール

このカテゴリではメールに関連する話を扱います。
迷惑メール、スパムメール、詐欺メールなどの内容に関する話、
メールプロトコルなどの技術面の話、
活用方法、代替技術など

難解になってきた、スパム（詐欺）メールの読み解き。

以下、 いっぱい来ている詐欺メール（怪しいメール）のうち、ひとつを生成AIに判別してもらいました。
プロンプトは次のように入れました。「＊＊＊」は伏字にしています。

メールの調査依頼 怪しいメールが来ました。調査をお願いします 文面は以下の通りです
--------------------------------------------
 社長からの指示で発注書を送付いたします。 ご確認よろしくお願いいたします。https://＊＊＊.zh-oulu.com/article/ppt

GPT4、 Grok4ともに「そのメールは 非常に高い確率でフィッシング（詐欺）メール です。」の判定です。

これのメールについては正解（True Positive）に違いないのでしょうが、問題はFalse Positive （スパムメールと誤判定してしまう）こともありました。 具体的には税務署からの物理郵送物でした。 GPT4は、 それは詐欺メールだと判定してしまいました。 税金支払わなかったたら追徴課税が来てしまいします。まるで、詐欺メールのように、恐ろしい。。。 税務署にはGPTに聞いても詐欺メールと判定されないように努力してほしい。 　しかし、 どういう判定基準なのかは、税務署など正式な役所の人よりも、詐欺側のほうが研究して、改善？して攻撃してくるので恐ろしい。
　20年以上前から電子署名などの仕組みはあるが、うまく活用できていない。 証明書のお値段が年間何万円もかかるのも、広まらない理由でもあるが、もう一つは１通ごとに証明書を計算しないといけないので配信処理のＣＰＵコストが高くなってしまうこともあるだろう。 なかなか難しい。 ただ、スパムフィルターも通り抜けている。。。
参考になるのは「https://ymg.nagoya/spam-mail-3057/」同じ攻撃を受けている人の投稿の存在。 この情報があれば、確実に詐欺と判断できますね。

以下、今回のメールのGrokの読み解き

調査結果の概要

ご提供いただいたメールの内容を調査しました。このメールは、典型的なフィッシング詐欺の特徴を強く示しており、絶対にリンクをクリックしたり、情報を入力したりしないよう強くおすすめします。以下に詳細をまとめます。

メールの特徴と危険性

  • 内容の不自然さ: 「社長からの指示で発注書を送付いたします」という文言は、ビジネスメールとして一見普通ですが、送信元が不明瞭で、具体的な会社名や詳細が欠如しています。こうした曖昧な表現は、受信者を油断させてリンクをクリックさせるための典型的な手口です。
  • リンクのURL: https://www.zh-oulu.com/article/ppt
  • このドメイン（zh-oulu.com）は、フィンランドのオウル大学（University of Oulu）と関連づけられた偽装名ですが、実際には正規の大学サイトではありません。類似ドメイン（例: web-zh-oulu.com）は、信頼性評価サイトで極めて低いスコアを付けられており、詐欺サイトの可能性が高いと判定されています。
  • ページの内容を直接確認したところ、ほとんど有用な情報がなく（「Insufficient relevant content」）、これはフィッシングサイトの典型的な兆候です。こうしたページは、アクセス後にリダイレクトやスクリプトを実行し、個人情報を盗むためのトラップを仕掛けています。
  • 特に、このURLは携帯電話番号の奪取を狙った不正サイトとして、X（旧Twitter）上で明確に警告が出されています。ページに表示されるフォームなどで番号を入力させるよう誘導する可能性が高いです。

なぜフィッシング詐欺か？

  • 類似事例の多さ: オウル大学関連のドメインを悪用したフィッシング攻撃は過去に複数報告されており、大学側もスパムやフィッシングの注意喚起を繰り返しています。 これは、信頼できる機関の名前を借りて信用を偽装する手口です。
  • 一般的なリスク: クリックすると、マルウェア感染、個人情報（電話番号、メールアドレス、パスワード）の盗用、またはさらなる詐欺メールの連鎖を引き起こす可能性があります。FTC（米連邦取引委員会）も、こうした「発注書」や「確認依頼」を装ったメールをフィッシングの典型例として警告しています。

推奨アクション

  1. リンクを無視: 絶対にクリックせず、URLをコピーしてブラウザのアドレスバーに直接貼り付けないでください。メール全体を削除するか、迷惑メールフォルダに移動。
  2. 送信元を確認: メールヘッダーをチェックし、送信元ドメインが本物の会社（例: @yourcompany.com）と一致するか確認。疑わしい場合は、直接会社に電話で問い合わせを。
  3. 報告する:
  • Gmail/Outlookなどのメールクライアントで「スパム報告」。
  • 日本国内の場合、警察のサイバー犯罪相談窓口（#9110）やIPA（情報処理推進機構）のフィッシング報告フォームへ。
  • 国際的に、PhishTank（https://phishtank.org/）にURLを登録。
  1. 予防策:
  • 2段階認証を有効化。
  • アンチウイルスソフトでメールをスキャン。
  • 疑わしいメールは常に上司やIT部門に相談。

このようなメールは増加傾向にあり、2024-2025年でも同様の事例がRedditなどで報告されています。 追加の詳細が必要でしたら、メールのヘッダー情報などを共有いただければ、さらに深掘りします。ご注意ください！

関連記事

スパムメール/詐欺メール DMARC設定で激減、2025年以降この設定は必須！？

スパム対策設定の成果

先のスパム設定の成果

設定対策後１ヶ月が経過しました。　先に公開した設定で、検出できなかったスパムは0件でした。　ただ、誤検知、つまり通常の配信メールなのにスパムと判定されたメールが4件ありました。これらは、除外設定で暫定回避して誤検出を抑制しています。

正式な誤検出対策の方法

誤検出を検出されたときに１件づつ除外設定をしなければならないのは面倒です。そこで、誤検出してしまった原因を確認して、その条件を除外することとします。
　DNSの逆引きで、unknownとなった送受信ログがあるものを対象としていますが、メースシステムの送受信でDNSで名前解決をせずに動作しているメールサーバーの存在が原因でした。つまり、メールの送信元がファイアウォール内のイントラネットであって、そこから中継サーバを経てインターネットに送信されています。

普通、メールサーバならイントラネット内でもDNSで名前解決するようにシステム設計するものなのですが、それなりにインターネットサービスをしている企業であっても名前解決・逆引きできないメールサーバがいくつかあります。DNS設定くらいしておいてほしいのですが、そんなことを言っても解決できないので、対処方法を考えてみます。
　　問題はイントラネット内でのUnknownですので、Unknwonが10.ｘ.ｘとか192.168.ｘとかのイントラネットIPなら除外する回避設定を正式対処としてみます。正規表現でUnknownかつ（10.ｘｘ.ｘｘ）でも（192.168.ｘ）でもｘｘｘでもない場合にスパムと判定するように見直します。といっても、メーラのフィルタにこのルールを設定できるのか疑問ですが。

スパム対策設定その後

先のスパム設定の結果と追加対策

対策前の１週間： 対象のスパムなどのメール は 284通。 これは振り分け前なので一部MLも含んでいる。 半数はスパム候補として判定されマークされている。一番対策したかったのは、メーラーやSpamAssassinでスパム判定し漏れてメインのメールボックスに入ってくる新しめ？のスパムでした。 100通/週くらいありました。

対策後の1週間；メインのメールボックスに入るスパムはほぼなくなり、１週間で２，３通でした。スパム判定の下メール内訳は次の通り、
先に追加したスパム判定ルールで検出したスパム：222通。うち、97通はメーラーやSpamAssassinでスパム判定し漏れたものでした。 追加したルールで引っかからず、メーラーやSpamAssassinで検出したものは157通ありました。　
　誤判定がないとは言えませんが、誤判定してしまうような環境から送信されたメールは不要としてしまってもよいかもしれません。数はほとんどないのでどうしても必要ならホワイトリストに入れることで回避できます。　スパムに困っている人は参考にしてください。

スパムメール対策 、おや多いと思ったら設定し漏れ…

最近スパムメールが増えてきたので、設定の見直しをしてみた。いくつかのパターンに分けて対策を試みる。

fromが自分のメールアドレスに偽装されているもの

このパターンは、一目でスパムとわかるので、まとめて削除できるが、事前に何とかならないか設定方法を見直してみる。
　このパターンは、サーバーで拒否してほしい。これは、送信元IPや送信元サーバーのドメインで判断できる。しかし、ここのレンタルサーバサービスでは提供されていない。仕方ないので、メーラで受信後に自動削除してみよう。
　メーラによって設定方法や設定ができるかどうか変わりますが、以下はThunderbirdでの設定方法です。
　ツール→メッセージフィルタ→新規→フィルタ名を入力→条件で”カスタムヘッダ”「Received」 に”次を含む”「.XXXX (unknown」を指定し、 動作に「メッセージ削除」を指定する。
　　この設定で、 *.XXXX ドメインと語るサーバー（本当のドメイン名unknownつまりDNSで逆引きできない）から送信されたメールを削除する。

特定IPからの送信を拒否

特定IPからの送信を拒否するより、送信元のメールアドレスが自分で、送信元のIPが自分以外のものを拒否するほうが効果的だろう。このパターンも レンタルサーバサービスでは拒否方法が提供されていない。同様に、メーラーで削除設定してみよう。上と、同様に
　仕方ないので、メーラで受信後に自動削除してみよう。
　ツール→メッセージフィルタ→新規→フィルタ名を入力→条件でカスタムヘッダ「差出人」に「次を含む」・「自分のメールアドレス」とand条件で「Received」 に「次を含む」、「unknown」を指定し、 動作に「メッセージ削除」を指定する。 「Received」 に「次を含む」、「(unknown」を指定し、 動作に「メッセージ削除」を指定する。※2019/12/26更新 普通にサービスされている正式なものにも意外に送信元名が設定されていないサーバーがあるので、IP逆引きできないものに限定することにした。これだけでも半数以上のスパムを処置できそうです。

以上の設定で、かなりの数のスパムメールが減るハズ。
とりあえず、1週間くらいこれで様子を見てみよう

spamの配信ツールはDNSキャッシュがずっと残る？

サーバが切り替わったので、古いサーバ宛のメールはほとんど来なくなりましたが、今日もまだ古いサーバに１件メールが来ていたので確認してみました。

”Security Notice. ……”というタイトルのspamメールでした。
送信ツールから、直接古いメースサーバ宛に送信されていました。普通のメールクライアントからの送信なら、送信用メールサーバーを経由するので、２段階以上の送受信となるはずですが、つぎのように、１段階だけでした。
　この部分をチェックするだけでも、何らかのツールを使って送信していることが分かります。

メールのソース
：省略
X-Mozilla-Keys:                                                                                 
Return-Path: <ｘｘｘ@mic.or.jp>
Received: from tm.82.192.61.119.dc.telemach.net (tm.82.192.61.119.dc.telemach.net [82.192.61.119])
 by mic.or.jp (Postfix) with ESMTP id 7070911002A03
 for <ｘｘｘｘ@mic.or.jp>; Wed,  9 Oct 2019 10:25:50 +0900 (JST)
From: ｘｘｘｘ@mic.or.jp>
To: <ｘｘｘｘ@mic.or.jp>
Subject: 
：省略

　　そして、DNSを切り替えて、１週間程度経過しているにも関わらず、古いサーバ宛に送信されています。 どこかにキャッシュされていたDNS情報を取得して古いサーバ宛に送信されたことが考えられます。しかし、今回のケースだと、１週間以上前にもメール送信した実績があり、その時に取得したDNS情報をキャッシュしていて、昨日メール送信する際にその情報を使ってメール送信したと考えるのが妥当でしょう。 メールマガジンの配信など大量メール送信ツールにはDNS情報のようにキャッシュできるものはキャッシュして性能を稼ぐ実装を採用しているものもあります。そのような技術をspam送信に利用しているのでしょう。

Pythonで日本語メール送信

定期実行タスクの機能を使ってメール送信していましたが、content-typeを次のようにcharsetを指定したいのに、

Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US

つぎのように指定されています。
Content-Type: text/plain; charset=ANSI_X3.4-1968

このcharset指定のメールでは、日本語の文面が文字化けしてしまいます。受信したメーラーで明示的に文字コードを指定することで文字化けは解消しますが、いちいち指定する手間が大変です。そこで定期実行タスクのメール送信機能は使わずに、Pythonから直接送信するように変更します。

Python2.6で使用するので、 Uchida さんのコードを参考にさせていただきました。

参考のための補足情報：

・デバック方法
smtp = smtplib.SMTP(c[‘host’], c[‘port’])
の次の行に 「 smtp.set_debuglevel(True) 」を追加することで、メールサーバとの通信内容を確認できます。

・ユーザー名、パスワードの指定にはダブルクオーテーションでくくるのはNGです。ダブルクオーテーションもユーザー名、パスワードとして送信されます。

user = <アカウント名>
password = <パスワード>

このPython実装でのメールでは、charsetは次のように設定されます。

Content-Type: text/plain; charset="iso-2022-jp"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

以上の設定により 、メールの日本語文面を文字化けせずに参照することができます。 これをベースに、脆弱性情報の通知メールに送信機能を組み込みます。

脆弱性情報の通知メールの仕掛けの更新

結構、動的に更新されるのか、頻繁に脆弱性ページが更新されています。
このため、先に作成した（5/9）、バージョンアップ情報や脆弱性対処を含むパッチの提供情報の通知メールが2,3日おきに飛んできます。WordPress5.3の作業も始まって、この更新分もあります。デイリーなのか更新頻度がどの程度なのかで、チェック方法を検討しなおします。
とりあえずメール文面を強化して簡単に更新内容をチェックできるようにしました。
今後、Webページの更新内容自体が、動的更新によるものかどうかを自動チェックして、通知するかどうかを切り分けるように強化します。※