【注意喚起】Peatixのフィッシングに認証情報を抜かれてしまった話【対応手順解説付き】

「フィッシング対策はやってる」——そう思っている情シスほど、今回の話は刺さると思う。

SPF/DKIM/DMARCを整えて、メールゲートウェイで不審メールを弾いて、添付ファイルはサンドボックスに通して。メール経由のフィッシングには、それなりに手を打っている会社は多い。でも先日、自分が見ていたある会社で、その対策がまるごと無力になる経路から認証情報を抜かれる事象が起きた。

結論から言うと、正規サービス（Peatix）の中のメッセージ機能経由のフィッシングだった。メール対策は1ミリも仕事をしてくれない。この記事は、その一次対応で情シスが実際にやった全手順を、生々しいまま残しておく。

▼何が起きたか：正規サービスのチャットに、フィッシングが紛れていた

集客媒体としてPeatixを使っているある会社で、Peatix内の個別メッセージ（チャット）に、フィッシングの連絡が複数届いた。文面は「アカウントに不審な動作が確認された」「アカウント認証をお願いします」という、典型的な“急かす”系のやつだ。

運用担当者がそのメッセージ内のURLを開き、遷移先のログイン画面でID・パスワードを入力してログインしてしまった。つまり認証情報が相手に渡った状態になった。発覚後すぐにパスワードは変更したが、「変えれば終わり」では当然ない。

SlackのDM、Salesforceの商談メモ、Notionのコメント、各種SaaSの通知欄——正規サービスの中にメッセージ機能がある時点で、それは全部フィッシングの“第4の経路”になり得る。メール対策の精度を上げても、この経路は別腹で空いている。

▼情シスがやった一次対応：6ステップの全手順

「パスワード変えました」で報告を終わらせると、後から穴が見つかる。今回実際に踏んだ手順を、順番含めてそのまま置いておく。

ステップ	やったこと
① 封じ込め	対象アカウントのパスワードを即変更。まずは相手が今すぐログインできない状態を作る。
② 影響範囲の特定	同じID/PW、または“似た”パスワードを他サービスで使い回していないかを棚卸し。完全一致だけでなく、部分使い回しも変更対象に含める。
③ 二次被害の確認	払い情報・銀行口座・連絡先メールアドレスが書き換えられていないか／メッセージ送信履歴を見て、なりすましで参加者へ二次フィッシングが送られていないかを確認。
④ セッション残存の確認	ログイン履歴・セッション一覧・強制ログアウト機能があれば確認し、不審セッションを切る。機能が無い場合はベンダーへ問い合わせ。
⑤ 全社注意喚起	同型パスワードの変更・多要素認証の有効化・パスワードマネージャー利用を全社にアナウンス。
⑥ CSIRT/関係者へ共有	事象のサマリ（経緯・現状・残課題）をセキュリティ窓口に共有し、記録に残す。

① 封じ込めより、②③④の“確認”の方が難しい

パスワード変更（封じ込め）は一瞬で終わる。本当に手間と判断が要るのは、「本当に封じ込められたか」を確認する②〜④だ。特に③の二次被害確認は見落としやすい。今回は払い情報や口座はそもそもサービス側に登録していなかったので無事だったが、もし主催者の口座情報や参加者リストにアクセスされていたら、被害は自社の外（参加者）に広がる。「自社アカウントが乗っ取られたか」だけでなく「そのアカウントから他人に何ができるか」まで見るのが情シスの仕事だ。

▼一番詰まったところ：強制ログアウトが無いSaaSの“確認できない”問題

今回、対応の中で一番厄介だったのが④のセッション確認だった。

パスワードを変えても、相手が既にログイン済みのセッションを持っていたら、そのセッションは生き続ける可能性がある。だからインシデント対応では「全セッションを強制ログアウトさせる」のが定石なんだけど——このサービスには、ユーザー側から強制ログアウトする機能も、ログイン履歴・セッション一覧を見る機能も無かった。

▼全社注意喚起は「複雑なパスワードを使いましょう」では動かない

⑤の全社アナウンス。ここで一番伝えたい小技がある。

「強いパスワードにしましょう」「使い回しはやめましょう」という一般論は、正直ほぼ誰も自分事として動かない。今回効かせるために使ったのは、実際に漏れたパスワードの“型”を抽象化して周知するやり方だ。

あわせて、社内アカウントはメールアドレスに紐づいて名寄せされることが多いので、IDが違っても同一・同型パスワードを使っているものは全部変更対象、という前提で周知した。「1個漏れたら同じ型は全滅扱い」で動く方が安全だ。生成・管理はパスワードマネージャー（KeeperやBitwarden等）に寄せる、というところまでセットで案内する。

▼今回の学び

学び	具体アクション
正規サービス内メッセージは“第4のフィッシング経路”	メール対策とは別軸で、「サービス内チャット由来の連絡も疑う」を周知に入れる
封じ込めより“確認”が難しい	PW変更だけで終わらせず、②使い回し ③二次被害 ④セッション まで定型チェック化する
セッション管理機能の有無は選定要件	SaaS棚卸しに「ログイン履歴・セッション一覧・強制ログアウト」の3点を追加
注意喚起は“型の抽象化”で効かせる	一般論ではなく「〇〇＋数字みたいな形式の人は変更」と具体化（実値は出さない）
パスワードはメアドに紐づく	ID違いでも同型は全部変更対象。「1個漏れたら同型は全滅」前提で運用

▼まとめ

• ▶ メール対策をどれだけ固めても、正規サービス内のメッセージ経由は別腹で空いている。
• ▶ 一次対応は「PW変更」で終わらせず、使い回し・二次被害・セッション残存まで定型で確認する。
• ▶ 強制ログアウト・セッション一覧が無いSaaSは、有事に“封じ込め完了”を自分で証明できない。選定時に効く。
• ▶ 全社注意喚起は、漏れたパスワードの“型”を抽象化して伝えると行動につながる。

フィッシングは「うっかり踏んだ人が悪い」で終わらせず、踏まれた後にどこまで定型で動けるかが情シスの腕の見せどころだ。今回の一次対応フローが、似た事象に当たったときのチェックリスト代わりになれば。