ソーシャルエンジニアリングは、人の判断や組織の手続きを悪用して、情報や操作を引き出す攻撃です。 偽サイト、電話、生成AIで作った音声や映像、マルウェアなどの技術も組み合わせられるため、単なる「人の不注意」として扱うことはできません。
ソーシャルエンジニアリングとは
システムを直接破らなくても、正規の利用者や担当者を動かせば、攻撃者は目的を達成できます。 ソーシャルエンジニアリングは、身分や状況を偽り、緊急性、権威、親近感などを利用して、認証情報、機密情報、不正な操作を引き出す攻撃の総称です。
攻撃者は、偽のログイン画面へパスワードを入力させたり、MFAの承認通知を押させたり、経理担当者へ振込先を変更させたりします。 どれも利用者や担当者自身が操作するため、システムのログには正規の操作に近い形で残る場合があります。
ただし、システム側で検知できないわけではありません。 普段と異なる端末や地域からのログイン、認証方式の変更、送金先の追加などを検知し、追加認証や承認を要求できます。 コードの脆弱性対策だけでは足りず、認証設計、業務手順、監視、報告後の初動を一つの防御として設計します。
主な手口のパターン
代表的な手口は次のとおりです。
- フィッシング：正規サービスや取引先を装ったメール、SMS、偽サイトなどで、認証情報やカード情報を入力させる
- スピアフィッシング：特定の個人や部署を調査し、実在する取引や人物に合わせて内容を作り込む
- ホエーリング：経営者など、権限や機密情報を持つ人物を狙うスピアフィッシング
- ビジネスメール詐欺（BEC）：取引先や経営者のメールを詐称または侵害し、振込、請求先の変更、機密情報の送付などを依頼する
- プリテキスティング：システム障害、監査、採用、上司からの緊急依頼など、もっともらしい口実を作って情報や操作を引き出す
- MFA疲労攻撃：不正ログインのプッシュ通知を繰り返し送り、利用者の誤承認や根負けを狙う
- ビッシング：電話や音声通話でIT部門、金融機関、取引先などを装い、認証コードや操作を要求する
- 物理的な手口：肩越しに画面を見るショルダーサーフィン、廃棄物から情報を得るトラッシング、正規の入館者に続いて入るテールゲーティングなど
BECは「経営層を狙うフィッシング」の別名ではありません。 経営者を装う場合もありますが、取引先の請求書を差し替える、従業員情報を送らせるなど、業務メールへの信頼を悪用する詐欺全体を指します。
組織としての対策
利用者が毎回詐欺を見抜くことを前提にせず、認証と業務手順の両方で誤操作の影響を抑えます。
- フィッシング耐性のある認証を導入する：パスキーやFIDO2セキュリティキーを使い、偽ドメインでは正規サービス向けの認証を成立させない
- 重要な依頼を別経路で確認する：振込先や連絡先の変更、機密情報の送付は、受信したメッセージに書かれた連絡先ではなく、事前登録した電話番号や社内システムで確認する
- 職務を分離する：高額送金、権限付与、MFAの解除などは、依頼者と実行者だけで完結させず、別の承認者を置く
- MFA疲労攻撃を抑える：単純なプッシュ承認から番号照合へ移行し、可能ならFIDO方式へ置き換える
- 報告後の手順を用意する：疑わしいメールを報告できる窓口を設け、セッション失効、送金停止、証拠保全、関係者への連絡をすぐ開始できるようにする
- 報告者を責めない：隠蔽や報告の遅れを避けるため、誤操作の申告を処罰と結びつけない
- 訓練を手順の改善につなげる：疑似フィッシングの結果を個人の成績表にせず、迷いやすい画面や確認経路を見直す材料にする
- 最小権限を徹底する：1つのアカウントが侵害されても、閲覧や操作の範囲を限定する
パスキーは、認証情報を偽サイトへ入力させるタイプのフィッシングに強い方式です。 WebAuthnでは認証情報がRP IDへ結びつくため、偽ドメインは正規ドメイン向けの署名を得られません。
ただし、パスキーがBECの振込依頼、ログイン後のセッションCookieの窃取、端末上のマルウェア、弱いアカウント復旧手順まで無効にするわけではありません。 パスキーの導入後も、重要操作の再認証、セッション保護、復旧手順の本人確認、業務上の承認を残します。
開発者とシステム側でできること
システム側では、認証の入口だけでなく、アカウント復旧と重要操作も同じ強度で保護します。
- パスワード、メールアドレス、MFA、復旧手段が変更されたら本人へ通知し、連絡先の変更時は変更前の宛先にも送る
- パスワード、ワンタイムコード、復旧コードを、電話、メール、チャットの担当者へ伝えさせる運用を作らない
- サポート窓口でのMFA解除やアカウント復旧に、ログインより弱い本人確認を使わない
- 高リスクな設定変更や送金では、操作内容を表示したうえで再認証や別担当者の承認を要求する
- 自社ドメインにSPF、DKIM、DMARCを設定し、監視後にDMARCポリシーを
quarantineまたはrejectへ移行する - ログイン、復旧、権限変更、送金先変更を監査ログへ残し、普段と異なる端末や地域からの操作を検知する
- セッションCookieを
Secure、HttpOnly、適切なSameSite属性で保護し、短い有効期限と失効手段を持たせる
SPF、DKIM、DMARCは、自社ドメインを無断で送信元に使う詐称を減らします。 見た目の似た別ドメインや、正規メールアカウント自体の侵害は防げないため、表示名や送信元認証の結果だけで重要な依頼を承認してはいけません。
番号照合も、単純な承認通知よりMFA疲労攻撃を難しくしますが、攻撃者が利用者へ番号を伝えて入力させる手口は残ります。 認証情報を狙うフィッシングにはFIDO方式を使い、送金や情報開示を狙う詐欺には別経路確認と職務分離を使うというように、守る操作へ対策を対応させます。