大和証券の委託先で不正アクセス：約22万件の漏えい可能性と、各チームの対応。

更新：2026年10月6日 10時50分（日本時間）。 大和証券の公開ヘルプページから分かる委託先サービスと、大和証券のオンライントレードのログインの仕組みを追記しました。下の「追記：ヘルプページとログイン」をご覧ください。この時点で、スカラコミュニケーションズと上場親会社のスカラは、インシデントに関するお知らせを公表していません。

発表で確認できること

委託先に保存されていた問い合わせ情報の事案であり、二次的な詐欺への備えが必要です。 どのシステムを調べ、顧客に何を案内するかを決めるうえで、この範囲の整理が重要です。

大和証券が2026年10月5日に公表した資料によると、問い合わせ管理等のサービスを提供するスカラコミュニケーションズ（SC社）から、同社サーバー上の顧客情報への不正アクセスと取得の形跡について報告を受けました。漏えいの可能性があるのは、約11万名の氏名、メールアドレス、口座番号等。個人を特定できる情報のない問い合わせ等を含めた総数が約22万件です。「人数」と「情報の件数」は同じ単位ではありません。大和証券の発表、1〜2ページ

発表上の不正アクセス期間は、10月2日20時33分頃〜3日8時1分頃。大和証券が連絡を受けたのは3日です。これは日本語の発表に記載された時刻であり、完全なフォレンジック時系列ではありません。SC社からは緊急のセキュリティ強化と、その時点で追加の不正アクセス・漏えいを確認していない旨の報告があったとされています。

大和証券は、自社システムへの不正アクセス、本件に起因する不正取引、情報のインターネット上への公開・拡散を確認していないと説明しています。また、対象情報だけでは口座へのアクセスや取引はできないとしています。対象顧客への個別連絡と委託先管理の点検を予定しています。いずれも発表時点の会社説明であり、二次被害の可能性がすべて解消したという第三者保証ではありません。発表原文

調査基準時点：2026年10月5日13時50分（日本時間）。 以下では公表内容とSecOpsNomadの分析・推奨事項を分けます。当社や委託先の内部調査資料にアクセスしたものではありません。

まだ公表資料からは分からないこと

確認した発表には、初期侵入の方法、悪用された脆弱性、マルウェア、攻撃者、身代金要求、本件固有の不正なIP・ドメイン・ハッシュは示されていません。情報項目の完全な一覧、問い合わせの保存対象期間、テナント単位の調査結果、確定した持ち出し量も不明です。基準時点までに確認した公開ページでは、委託先による独立した本件の発表は見つけられませんでした。

「取得の形跡」は単なる脆弱性の可能性より重大な情報ですが、影響する顧客と記録の全体像は照合が必要です。「何も取られていない」とも「22万の取引口座が侵害された」とも言い換えられません。委託先での事案だけを根拠に、ソフトウェア更新への不正混入や、その委託先の全顧客への被害を認定することもできません。

続報で確認したいのは、侵入経路、対象サービスとテナントの範囲、閲覧と取得を区別する証拠、保管された問い合わせの年代・項目、恒久対策、対象顧客の特定方法です。公表されていないことは、その対策が存在しなかった証拠にはなりません。

追記：ヘルプページとログイン

大和証券のヘルプページはスカラコミュニケーションズの製品で動いている

大和証券のお知らせは、スカラコミュニケーションズのどのサービスかを明らかにしていません。公開されているFAQに手がかりがあります。FAQはdaiwa.dga.jpから配信され、各ページに「Powered by i-ask」のバッジがあり、**スカラコミュニケーションズのFAQシステム「i-ask」**の製品ページにリンクしています。大和証券よくあるご質問、i-ask製品ページ。

編集部の評価。 これで分かるのは、大和証券のヘルプページがスカラコミュニケーションズの製品で動いていることです。問い合わせ履歴を保存し、不正アクセスを受けたのがどのシステムかは分かりません。 i-askはFAQシステムであり、大和証券のお知らせが述べているのはインターネット経由の問い合わせ内容を管理するサービスです。別の製品や機能である可能性があります。また、他のi-ask導入企業が影響を受けたことを示すものでもありません。製品ページには他の導入企業が掲載されていますが、この追記の時点で影響を公表した企業はありません。

委託先リスク管理チームにとって有用なのは具体的な確認です。自社のヘルプ、FAQ、問い合わせページに、委託先のバッジやこのような委託先ホストのサブドメインがないかを確認し、該当する委託先に自社テナントが対象かを直接問い合わせてください。公表を待つ必要はありません。

口座番号だけではログインできない

大和証券は、2026年4月から6月にかけて段階的に、オンライントレードのログインでパスキー認証を必須化しました。大和証券フィッシング詐欺への注意喚起、大和証券パスキー認証のページ。氏名、メールアドレス、口座番号は認証情報ではありません。漏洩した可能性のある情報だけでは口座へのアクセスや取引はできないという大和証券の説明と整合します。

リスクは顧客側に移ります。大和証券自身のFAQは、電話認証がパスキーより弱い理由を説明しています。リアルタイム型フィッシングでは、顧客が偽のログイン画面に支店コード・口座番号・ログインパスワードを入力します。犯人はそれを同時に本物のサイトへ入力し、本物のサイトで表示されるのと同じ認証用電話番号を顧客の画面に表示して、電話を掛けさせます。電話認証が完了すると、犯人の不正ログインが成功します。パスキー認証ならこの手口を防げると大和証券は説明しています。大和証券FAQ：なぜ電話認証の方がセキュリティ強度が低いのか。

編集部の評価。 今回の事案については、次の2点が言えます。

漏洩した記録は、この中継型の手口の入口を作りやすくします。 顧客の本名、口座番号、最近の問い合わせの内容を引用したメッセージは、一般的なフィッシングよりはるかに信じられやすくなります。大和証券のFAQでは現在、パスキー登録やログインパスワードに関する質問がよく見られている質問に並んでいます。漏洩した問い合わせの内容は分かりませんが、「パスキー登録に関するお問い合わせの件、こちらから設定を完了してください」といった文面は、実際に問い合わせをした顧客に届く可能性があります。
注意すべきは口座連携の手順です。 既存の証券口座を新しいパスキーのアカウントに連携する際には、支店コード、口座番号、ログインパスワードと電話認証を使います。大和証券パスキー認証のページ、手順3-4と3-5。この手順が同じ中継の手口に対してどう守られているかを、大和証券は明らかにしていません。より弱い要素を起点にパスキーを登録させる企業すべてに当てはまる問いです。パスキーの強さは、それを登録した手順の強さを超えません。

同様の設計を持つ企業の不正対策・ID管理チームは、問い合わせや着信の直後に新しいパスキーや端末が口座に連携された場合にアラートを出し、連携のたびに別の経路で顧客に通知し、連携直後の出金や連絡先変更を高リスクとして扱ってください。

大和証券の顧客が今できること

パスキーの設定や変更は、公式アプリかブックマークしたログインページからだけ行う。 メッセージ内のリンクからは行わないでください。大和証券は、オンライントレードのログインページのURLはhttps://www.daiwa.co.jp/から始まるとしています。
送信元を確認する。 大和証券は送信元アドレスを@daiwa.co.jp、ddfx@fxmail.daiwa.co.jp、dd365fx@365fx.daiwa.co.jp、daiwa_info@mail.daiwa.co.jp、noreply@accounts.daiwa.co.jpとしており、2026年1月11日以降のメールには、対応するメールサービスでブランドロゴが表示されます。大和証券フィッシング詐欺への注意喚起。
ログインや取引の「操作通知」を有効にし、大和証券が勧めるとおり、出金などの重要な手続きにはワンタイムパスワードを設定する。
メッセージからたどり着いたページに表示された認証用の電話番号には、絶対に電話しない。 大和証券が説明する中継の手口では、その電話が犯人のログインを承認します。

問い合わせ履歴がセキュリティ態勢に与える影響

運用上は、情報の機密性、信用されやすいなりすまし、口座の保護を別々の課題として管理し、証拠で関連付ける必要があります。

委託先の情報流出範囲、なりすましの有無、口座操作の正当性を別々に調べる三つの対応領域。

SecOpsNomad作成の分析図。後続のなりすましや口座悪用は調査シナリオであり、本件で確認された出来事ではありません。

1. 取引の基幹システム以外にも重要な顧客情報がある

問い合わせシステムには、顧客の身元、企業との関係、相談の履歴が保存される場合があります。自由記述、出力済みレポート、バックアップ、添付ファイルを含め、実際に何を保存しているかを確認します。本件で添付ファイルが存在した、または流出したという意味ではありません。

委託先の重要度は「取引処理を行うか」だけでなく、保有するデータと権限で判断することを推奨します。不要な口座識別情報を減らし、認証の秘密情報をチケットに転記させず、一括出力を制限します。保存期間は現用データと復元可能なコピーの双方で定義します。保管期間の変更や削除を行う前に、必要な証拠保全を実施してください。

2. 正しい個人情報を知っている相手でも本人とは限らない

実際の問い合わせ内容を知る電話やメールは、一般的な詐欺より信用されるおそれがあります。しかし、問い合わせ履歴や口座番号を知っていることを本人確認の根拠にしてはいけません。アカウント回復、連絡先変更、例外的な承認で、独立した確認手段が機能するかを点検します。

防御計画では、サポート担当、漏えい通知窓口、補償窓口へのなりすましを想定します。これは可能性を検討するシナリオであり、本件に紐づく攻撃キャンペーンを観測したという主張ではありません。従業員には、相手に回復手続きを教え込むことなく、連絡経路と要求内容を検証できる手順が必要です。

3. 口座監視は独立した対応として続ける

情報の機密性に関する事故と不正取引は異なる事実です。実際に利用可能な機能に応じて、ログイン、回復申請、新しい端末、MFA変更、重要な口座操作を確認します。顧客からの申告と相関させる際は、個人情報へのアクセスを必要最小限にします。

金融庁は、正しいブックマークや正規アプリの利用、提供されるセキュリティ機能や通知の有効化、不審な取引への注意を呼びかけています。これは証券口座全般に対する注意喚起であり、他の不正取引が本件に起因することを示す資料ではありません。金融庁の注意喚起

どのチームが確認すべきか

チーム	まず確認する問い	証拠・対応
委託先リスク管理・調達	直接または再委託を通じて対象サービスを利用しているか	サービス、テナント、情報区分、契約窓口、調査資料へのアクセスを確認。全製品が対象とは決めつけない
アプリ責任者・データ保護担当	何を送り、保存し、出力していたか	項目と保存期間を整理。記録件数と実人数を分け、正当な出力履歴と連携権限を確認
SOC・SIEM	委託先の事象と自社の認証・申告を結び付けられるか	監査ログ、時刻、タイムゾーン、収集欠落、相関IDを保全し、対象を絞った証拠を依頼
メールセキュリティ	関連するなりすましメールが届いているか	原本・ヘッダー、配信、URL、受信者の申告を確認。正規の通知を誤遮断しない
EDR・DFIR	申告されたメールからダウンロードや実行が発生したか	根拠のある端末と時間帯を調査。委託先の発表だけで全端末を隔離しない
IAM・不正取引対策・サービスデスク	既知の個人情報が回復や変更手続きに悪用されていないか	独立した本人確認を行い、説明できない変更・取引を所定の経路でエスカレーション
法務・プライバシー	どの主体・データにどの義務が適用されるか	認知時点、報告先、本人通知の範囲、証拠保全、続報の責任を整理
広報・顧客サポート	本物の案内を顧客が確認できるか	公式の更新ページ、確認済み窓口、秘密情報を求めない応対手順を統一

該当サービスを利用していない組織でも、類似する問い合わせ・CRMの委託先点検に活用できます。影響者リストを作る目的で、従業員個人の金融取引情報を探索することは適切ではありません。

証拠に基づく対応の順序

範囲を確定し、委託先との境界を保全する

インシデント責任者を決め、既知の窓口で委託関係と対象サービスを確認します。確度を明記した書面での範囲説明を求めます。
アプリ、認証、API、出力、保守アクセスのログを保全します。元のタイムゾーン、保存期間、既知の欠落を記録します。公表期間だけでは、それ以前に活動がなかったとは証明できません。
対象オブジェクト、操作主体、時刻、操作内容、出力・転送記録など、テナント固有の証拠を依頼します。「新たなアラートがない」と「追加アクセスがない」は同じではありません。
連携とサービス認証情報を確認します。関連が認められる認証情報を承認済みの変更手順で失効・更新し、すべての顧客の認証情報が流出したとは仮定しません。

状況に合った分岐を選ぶ

判断	はいの場合	いいえ・不明の場合
自社テナント・データが対象と確認されたか	記録と実人数を照合し、プライバシー責任者と必要な通知を計画	範囲を限定した回答を求め、不確実性と次回確認の担当を記録
不審なメール・電話の申告があるか	証拠を保全し、独立した経路で送信者と要求を確認	申告経路を維持。申告がないことを攻撃がない根拠にしない
認証情報の入力、MFA承認、ソフト導入があったか	実際の操作に応じてID・端末対応を開始し、セッション封じ込め等を検証	影響の大きい対応に進む前に操作の証拠を確認
説明できない口座変更・取引があるか	正規の金融機関の不正取引対応窓口へ直ちに連絡	相応の監視を続け、確認できた範囲を記録
復旧を進める段階か	侵入経路への対策、ログの動作、責任者による残存不確実性の判断を確認	合意した封じ込め計画内でサービスや連携を管理

不審な連絡にはフィッシング対応プレイブック、ID悪用の根拠がある場合にはアカウント侵害対応プレイブックを利用できます。委託先サービスの復旧と顧客への詐欺調査の終結は、別々に判断します。

ハンティング：IOCを作らず、証拠に備える

確認した発表には本件固有のIOCはありません。 大和証券やSC社の正規ドメインを不正な指標として扱わないでください。以下は調査権限のある環境に対する読み取り専用のテンプレートであり、本件への関与を判定する検知ルールではありません。問い合わせ履歴や口座番号を公開の調査サービスやLLMへ投入しないでください。

KQL 1 — 申告のあった受信者1名の関連メールを確認

対象はMicrosoft Defender XDRのAdvanced Huntingです。Defender for Office 365とメールメタデータの参照権限が必要です。受信者を実際の対象に置き換え、利用可能な期間を確認します。時刻列はSentinelのTimeGeneratedではなくTimestampです。件名・表示名のブランド語は確認の手掛かりであり、正規通知、ニュース、案内メールも一致します。別の表現や本文だけの記載は見逃し得ます。送信認証とURLは別途確認し、検索結果をそのまま遮断リストにしないでください。MicrosoftのEmailEvents仕様

受信者メール確認クエリをダウンロード

// Defender XDR Advanced Hunting. Read-only; not live-tested.
let TargetRecipient = "REPLACE_WITH_REPORTED_RECIPIENT";
EmailEvents
| where Timestamp between (ago(7d) .. now())
| where EmailDirection == "Inbound"
| where RecipientEmailAddress =~ TargetRecipient
| where Subject contains "大和証券" or Subject contains "Daiwa"
    or SenderDisplayName contains "大和証券" or SenderDisplayName contains "Daiwa"
| project Timestamp, NetworkMessageId, RecipientEmailAddress,
    SenderFromAddress, SenderDisplayName, Subject, DeliveryAction,
    DeliveryLocation, ThreatTypes, AuthenticationDetails
| order by Timestamp desc
| take 500

KQL 2 — 選定したメールのSafe Linksクリックを確認

前の結果や調査から得た、確認済みの正確なNetworkMessageIdを指定します。UrlClickEventsの収集が必要です。許可されたクリックは認証情報入力の証明ではありません。結果がない理由には、収集範囲・保存期間・別経路の利用・クリックなし等が考えられます。電話や管理対象外の個人メールは観測できません。MicrosoftのUrlClickEvents仕様

メールクリック確認クエリをダウンロード

// Defender XDR Advanced Hunting. Read-only; not live-tested.
let TargetMessageId = "REPLACE_WITH_REVIEWED_NETWORK_MESSAGE_ID";
UrlClickEvents
| where Timestamp between (ago(7d) .. now())
| where NetworkMessageId == TargetMessageId
| project Timestamp, NetworkMessageId, AccountUpn, Url,
    ActionType, ThreatTypes, Workload
| order by Timestamp desc
| take 500

Splunk — 1アプリ・1テナントの問い合わせ操作を確認

独自の監査スキーマ用テンプレートであり、委託先の実際のログ形式を示すものではありません。app_id、tenant_id、actor_id、action、object_id、result、src、event_idを、自社が参照権限を持つアプリまたは提供者のログに対応付けます。actionは検索内の値へ正規化してから使用します。未対応の項目があると、エラーなしでイベントを見落とす場合があります。インデックス、ソースタイプ、テナントを限定してください。

正当な出力・保守作業・失敗した操作も結果に含まれ得るため、承認記録と原本に照合します。結果行数は、顧客数や持ち出された記録数ではありません。Splunkのwhere仕様

委託先監査クエリをダウンロード

index="REPLACE_WITH_AUDIT_INDEX" sourcetype="REPLACE_WITH_AUDIT_SOURCETYPE" earliest=-7d latest=now
| where app_id="REPLACE_WITH_EXACT_APP_ID" AND tenant_id="REPLACE_WITH_EXACT_TENANT_ID"
| where action IN ("read", "download", "export", "permission_change")
| sort 500 + _time
| table _time app_id tenant_id actor_id action object_id result src event_id

直近7日間は公開時の初動確認用です。後日調査する際は、先行活動や取り込み遅延も考慮し、証拠に基づく固定期間へ変更します。500行の制限は出力件数であり、走査コストの上限ではありません。上限に達した場合は期間を分け、必要な完全な記録を別途保全します。実行状況：文書・スキーマの確認のみ。実テナントでは未実行です。 日英のコードとダウンロード内容は同一です。

プライバシー対応と顧客への案内

法務担当は、報告・本人通知の要否、担当主体、関連する事実を認知した時点を確認します。公表日時がそのまま法定の起算点になるわけではありません。個人情報保護委員会は、速やかな速報と続報の対応、業種による報告先等を案内しています。最終的な件数が未確定であることだけを理由に報告を先延ばしにしないでください。個人情報保護委員会の対応案内

通則編には、委託元と委託先の義務や、委託先から委託元への通知が報告義務に影響する条件が示されています。実際の関係を法務担当が判断する必要があり、契約や委託先の公表だけで、各組織の対応がすべて完了したとは判断できません。個人情報保護委員会の通則編

顧客側では、使い慣れた正規アプリや確認済みブックマークから通知・利用状況を確認し、独立して確認した窓口へ相談してください。提供されている保護機能も有効にします。不審なやり取りの中で認証情報の入力、MFA承認、ファイルの導入をした場合は、不正取引の確定を待たず、その操作を速やかに伝えます。突然の電話にパスワード、暗証番号、ワンタイムコードを渡さないでください。金融庁の注意喚起、大和証券の正規お問い合わせページ

どの続報で判断を見直すか

侵入手法や脆弱な製品が確定すれば、対策の優先順位が変わります。検証済みのIOCが公表されれば、対象を限定した過去ログ検索に利用できます。対象者や情報項目の修正は通知と詐欺対策に影響します。認証情報の侵害、不正な口座操作、委託先での影響拡大が確認されれば、新たな対応領域が必要です。

現時点での実務上の教訓は、委託先にある顧客とのやり取りをデータ責任者・SOC・不正取引対策担当が把握し、組織の境界を越えて証拠を確認できるようにすることです。これはSecOpsNomadの分析であり、大和証券の既存対策の妥当性や金銭被害を断定・予測するものではありません。

2026年10月6日 — 更新。 「追記：ヘルプページとログイン」を追加しました。大和証券のFAQにあるi-askのバッジ、パスキー認証の必須化、電話認証に対するリアルタイム型フィッシングについての大和証券自身の説明、口座連携の手順に関する問い、大和証券が公表する送信元アドレスを含む顧客向けの対策です。出典は10時50分（日本時間）に再確認し、委託先のお知らせは公表されていませんでした。既存の本文は変更していません。

2026年10月5日 — 初版公開。 一次発表と公的ガイダンスに基づく独自の日英分析・図解です。流出データ、非公開の調査資料、架空のIOCは含みません。

30秒でわかる要点