Torを使ったサイバー攻撃の戦術とその対策案(転載)



Torを使ったサイバー攻撃の戦術とその対策案:

US-CERTより、FBIとの共同寄稿として、Torを使ったサイバー攻撃の戦術およびその対策案についてのアラートが発行されました。

本記事では、US-CERTの記事を中心として、Torについて、また、最近何かと話題のATT&CKについてご紹介しつつ、解説していこうと思います。

まずTorについて

Torは、The Onion Routerの略で、ユーザが特定のサイトにアクセスする際に、いくつものノードを経由して接続することで、元の通信先を秘匿する暗号化通信技術を用いたソフトウェアです。

通信を中継するノード間の通信は暗号化されているため、盗聴や改ざんも防止されています。

以下は、@ITが公開している記事の図です。参考の図として掲載しておきます。


そしてこのソフトウェアはTorプロジェクトによって管理されています。

www.torproject.org

元々はインターネットの民主性と匿名利用の促進のための使用を意図されていましたが、攻撃者にとっても好都合であるこの技術は徐々に悪用されるようになりました。

実はこのTor、名探偵コナンの映画でもNorと名前を変えて登場していました。

ちなみに、こんなロゴです。

f:id:micro_keyword:20200703161302j:plain:w400

玉ねぎが白菜になっていますが、NorだからOnionが抜けてないやん!みたいなテンションですが(笑)

まあ、アニメだし、そんなことを言い始めたらコナン君空飛んだりするし。。


Torのアクセスはたどれないの?

先ほど述べたTorの技術により、通信時の送信元や、通信経路におけるネットワーク監視、トラフィック分析を困難にしています。

その結果、最終的に宛先のサーバへ通信を行うTorのExitノードからの通信情報のみしか、分析などで活用できないというのが勘所です。

ちなみに、中継点であるノードを一つ一つ、たどっていけば、理論的には送信元IPをたどることは可能なはずです。

ただし、それらノードの管轄は別々の国、別々の管理者の所有物であるボランティアサーバであり、それらをすべての通信をつなぎ合わせるためには中継点すべてのノードの管理者の協力が必要となります。

現実的には不可能だと思います。

さらに言うと、Torの中継ルートは一定時間で変更されることから難易度はさらに高いといえます。


Torを利用した攻撃の戦術

さて、ここからは、MITREが公開しているATT&CKフレームワークに基づいた攻撃戦術のお話をしていきます。

ATT&CKとは

ATT&CKと書いてアタックと読みます。

そうなんだ~って感じですよね。(怒られそう(笑))

このATT&CKは脆弱性の識別子CVEの発行組織として有名なMITRE社が開発した、攻撃の手法や戦術を体系化したフレームワークです。

attack.mitre.org

このフレームワークの利用によって、

攻撃グループやマルウェアがサイバー攻撃におけるどの段階のどんな戦術と関連があるのか

がわかります。

攻撃の段階として、よく用いられるサイバーキルチェーンで示すと、Exploit以降の段階をATT&CKでは示しています。


上図は、McAfeeのブログを参照(引用元はMITRE社)

最近公開されている、標的型攻撃の記事などでは、記事のAppendixとして、IoCに添えてATT&CKの指標が書かれることが多いので、注目してみるといいかもしれません。

Torを用いた悪意のある活動

Torを用いた攻撃の活動としては以下が挙げられています。

  • Pre-ATT&CK(侵入準備段階)
    • 標的の選択
    • 技術情報収集
      • アクティブスキャンの実行
      • パッシブスキャンの実行
      • ドメインとIPアドレス空間の決定
      • セキュリティ防御機能の特定
    • 技術的な弱点の特定

  • ATT&CK(侵入後)
    • 初期侵入
      • 公開されたアプリケーションへの侵入
    • C&C(コマンド&コントロール)
      • Well-Knownポートの利用
      • プロキシの利用
      • カスタムコマンドや制御プロトコルの利用
      • カスタム暗号化プロトコルの利用
      • 多段プロキシの利用
      • 多段暗号化の利用
      • 標準アプリケーション層プロトコルの利用
    • 情報窃取
    • データ破壊や改ざん
      • データの暗号化(ランサムウェアなど)
      • エンドポイントのDoS(サービス拒否)
      • ネットワークのDoS(サービス拒否)

Torを利用した攻撃のへの対応策

US-CERTのアラートでは、Torを利用した攻撃を検出するための手法として、例を紹介しています。

ExitノードのIPアドレスを用いた検知

Torプロジェクトより、TorのExitノード一覧が公開されています。

blog.torproject.org

このリストをSIEMやログ分析プラットフォームに取り込むことで、不審な通信が発生した際の検知を可能にできます。

なお、このExitノード一覧は1時間ごとに更新されるので定期的な更新が推奨されます。

Torを用いた通信の特徴を踏まえた検知

  • Torの通信で利用させるポート
    • 9001
    • 9030
    • 9040
    • 9050
    • 9051
    • 9150
  • ドメイン名の末尾
    • torproject[.]org
    • [.]onion
      • Torネットワーク内のドメイン
      • Tor内のC2サーバへ接続を試みた場合に検知される可能性あり
これら、Torを用いた際の通信の特徴をセキュリティ機能の検知ルールに加えることで、検知が可能になります。

具体的な防御策

  • 定常運用において
    • TorのEntryノードおよびExitノードのIPアドレスリストを常に最新に維持する
  • SIEMの活用
    • Torの使用状況をインバウンドおよびアウトバウンドの両面の通信から把握できる運用を行う
  • ネットワークトラフィックの検査
    • トラフィックの検査を行い、Tor利用状況における通常時のトラフィック量を把握することで、異常を早期に検知する
  • インバウンド通信制御
    • 既知のExitノードからの通信のブロックもしくは監視設定をセキュリティ機器およびソフトウェアに設定する
    • Tor通信の特徴的なポート番号利用をブロックもしくは監視する
  • アウトバウンド通信制御
    • 組織からEntryノードへの通信のブロックもしくは監視設定をセキュリティ機器およびソフトウェアに設定する
    • Tor通信の特徴的なポート番号利用をブロックもしくは監視する

まとめ

今回は、US-CERTのアラートを中心にTorを用いた攻撃やその対応策についてご紹介しました。

とはいえ、あまりピンとこない方も多いと思いますし、「百聞は一見に如かず」ということで、一度Torを使ってみるのもよいかもしれません。

わかりやすい例がないかなーと思って事例を探してみたのですが、日本の記事だとLACが出している以下の記事くらいしか見当たりませんでした。

とはいえ、攻撃の流れ含めわかりやすいと思いますので、ぜひご参考にしてみてください。

www.lac.co.jp

マルウェア感染に備えてアンチウィルスソフト以外に入れておくべきもの 【Toolwiz Time Freeze】


アンチウイルスソフトは基本的にパターンマッチング方式なので、パターンにマッチしなければ駆除できない。

現在武漢ウイルスが世界中に蔓延しているが、ワクチンが無いため、対処療法でしのぐしかないのと同じ状況である。

感染時にワクチンが無いので根本的な治療ができないのは理解したが、そもそもウイルス感染前の状況に時間を戻すことができないのか?

人間であれば明らかに無茶な話であるが、ITの世界では無茶な話ではない。

それを実現するためのツールが今回紹介する、

Toolwiz Time Freeze

である。

このツールを使うと、再起動するだけで開始時点からの変更を元通りにできる。

「変更」というのは、マルウェア感染も含まれる。

ただ、常時起動させっぱなしだと、ファイルの変更や必要なアプリのインストールを行っても再起動するとリセットされてしまうため、注意が必要。

一方で、アプリをインストールするとOSの挙動が不安定になる時もあったりするので、
インストール行為そのものに不安がある場合や、不審なサイトに冒険に行くような場合に起動しておくのが良い。

人でいうと予防接種の様な位置づけだろうか。

【参考】
https://kaciy-discovery.hatenablog.com/entry/2017/12/16/120157
https://www.japan-secure.com/entry/blog-entry-299.html
https://all-freesoft.net/system8/virtualsystem/toolwiztimefreeze/toolwiztimefreeze.html

【製作者サイト】
http://www.toolwiz.com/

※投稿時点のバックアップ(ver2017)はこちら

ATT&CKを始めよう:アセスメントとエンジニアリング / Getting Started with ATT&CK: Assessments and Engineering(転載)


Getting Started with ATT&CK: Assessments and Engineering

ここ数週間、ATT&CKを使った脅威インテリジェンス、検知・分析、敵のエミュレーションなど、ATT&CKを使いこなすための記事を掲載してきました。ミニシリーズのパート4では,評価とエンジニアリングについて,ATT&CKを使ってどのように防御力を測定し,改善できるかをご紹介します。この記事は多くの点で過去の記事を基にしていますので、まだご覧になっていない方はぜひチェックしてみてください。 

このプロセスをよりわかりやすくするために、また、他の記事と同様に、この記事を洗練度とリソースの有無に応じて3つのレベルに分けています。

  • レベル1は、リソースをあまり持たない始めたばかりのチーム向け。
  • レベル2は、成熟し始めた中レベルのチーム向け
  • レベル3は、より高度なサイバーセキュリティ・チームとリソースを持つ企業向けです。

評価を始めることは、最初は恐ろしく聞こえるかもしれません-誰が評価されることを喜ぶでしょうか?- しかし、ATT&CKのアセスメントは、セキュリティエンジニアやアーキテクトが脅威に基づくセキュリティの改善を正当化するための有用なデータを提供するための、より大きなプロセスの一部です。

  1. ATT&CKに登場する技術や敵に対して、現在の防御力がどのようになっているかを評価。
  2. 現在のカバー範囲の中で最も優先度の高いギャップを特定。
  3. それらのギャップに対処するために、自社の防御力を修正したり、新たな防御力を獲得。

アセスメントとエンジニアリングのレベルは累積的であり、互いに積み重ねられていきます。自分たちが高度なサイバーセキュリティチームであると考えている場合でも、レベル1から始めて、より大規模なアセスメントに移行するためのプロセスを踏むことをお勧めします。

多くのリソースを利用できない小規模なチームで作業していて、完全な評価を行おうと考えているならば、やめた方がいい。すぐにATT&CKマトリックスの色分けされたヒートマップを作成してカバレッジを可視化するというアイデアは魅力的ですが、ATT&CKを使うことに興奮するよりも、ATT&CKに燃え尽きてしまう可能性の方が高いでしょう。その代わり、小さなことから始めましょう。焦点を当てるべき1つの技術を選び、その技術に対するカバレッジを決定し、それを検出するために適切なエンジニアリングの強化を行います。このように始めることで、より大規模な評価を行う方法を練習することができます。

ヒント:どの手法から始めるべきかわからない?ケイティのブログ記事では、ATT&CKやスレットインテリジェンスをどのように使ってスタート地点を選ぶかのヒントを紹介しています。

テクニックを選んだら、そのテクニックをどのようにカバーするかを考えてみましょう。独自のルーブリックを使用しても構いませんが、まずは以下のカテゴリーでカバーすることをお勧めします。

  • 既存のアナリティクスでその手法を検出できる可能性が高いカテゴリ。
  • アナリティクスでは検出できないが、検出するために適切なデータソースを使用しているカテゴリ。
  • 現在、そのテクニックを検出するための適切なデータソースを利用していないカテゴリ。

ヒント:最初に始めるときには、スコアリングのカテゴリーをシンプルにしてください。

カバー率の測定を始めるための素晴らしい方法は、ある技術をすでにカバーしている可能性のあるアナリティクスを探すことです。SOC の多くは、本来は ATT&CK に対応するように設計されていなくても、ATT&CK に対応する可能性のあるルールやアナリティクスをすでに持っています。多くの場合、テクニックに関する他の情報が必要になりますが、それはテクニックのATT&CKページや外部ソースから得ることができます。

例として、Remote Desktop Protocol(T1076)を調べていて、以下のようなアラートがあったとします。

  1. ポート22を介したすべてのネットワークトラフィック。
  2. AcroRd32.exeによって生成されたすべてのプロセス。
  3. tscon.exeという名前のすべてのプロセス。
  4. ポート 3389 を介したすべての内部ネットワーク トラフィック。

ATT&CKのテクニックページのRemote Desktop Protocolのページを見ると、ルール#3が "detection "ヘッダで指定されている内容と一致しており、ウェブ検索をすると、ルール#4で指定されているポート3389もこのテクニックに対応していることがわかりました。

Remote Desktop Protocolの検出用テキスト。

もし、アナリティクスがすでにそのテクニックをピックアップしているなら、素晴らしいことです。そのテクニックをカバーしていることを記録し、新しいテクニックを選んで再度プロセスを開始してください。しかし、それをカバーしていない場合は、テクニックのATT&CKページに記載されているデータソースを見て、新しい分析を構築するのに適したデータをすでに取り込んでいるかどうかを判断します。もしそうであれば、あとは構築するだけです。

しかし、正しいデータソースを引き込めていない場合、どうすればいいのでしょうか?ここでエンジニアリングの出番です。技術のATT&CKページに掲載されているデータソースを参考にして、それぞれのデータソースを収集することの難しさと、そのデータソースを利用することの有効性を比較してみてください。

ヒント データソースとしてよく挙げられるのが、Windowsのイベントログで、多くのATT&CKテクニックを可視化することができます。イベントログを使い始めるのに適したリソースは、Malware ArchaeologyのWindows ATT&CK Logging Cheat Sheetで、Windowsイベントとそれを使って検出できるテクニックをマッピングしています。

プロセスのコマンドラインパラメータで検出可能な244種類のATT&CK
技術のうち97種類を、Windowsイベント4688を介して取り込みます。

次のレベルへの卒業:このプロセスを何度か繰り返し、その都度、各戦術にまたがる新しいテクニック(または2つ)を選んでください。ATT&CK カバレッジのヒートマップを作成できる ATT&CK ナビゲーターを使って、結果を記録しましょう。プロセスに慣れてきたら、データソースの分析を行い、データソースからどのテクニックを検出できるかをヒートマップで表示します。Olaf Hartong氏のATT&CK DatamapプロジェクトDeTT&CT、MITREのATT&CKスクリプトなどがありますので、参考にしてください。

Level 2

このプロセスに慣れ、より多くのリソースを利用できるようになれば、ATT&CK マトリックスの適度に大きなサブセットにまで分析を拡大することが理想的です。さらに、より高度なカバレッジスキームを使用して、検出の忠実性も考慮したいと思うでしょう。ここでは、SOC内のツールや分析ツールがその技術について警告を発する信頼性が低い、ある、高いのいずれかにカバレッジを分類することをお勧めします。

最終的にどのような評価をするかのサンプル。

ヒント カバレッジを評価する際には、ピンポイントの精度を気にする必要はありません。評価の目的は、技術を一般的に検出するためのエンジニアリング能力があるかどうかを理解することです。より正確な評価を行うためには、敵のエミュレーション演習を行うことをお勧めします。

このように範囲が広がったことで、アナリティクスの分析はやや複雑になっています。各アナリティクスは、以前のように1つのテクニックだけでなく、多くの異なるテクニックに対応する可能性があります。さらに、ある分析手法がカバーされている場合、その分析手法の忠実度も調べる必要があります。

ヒント 各アナリティクスについて、何をキーにしているかを調べ、それがATT&CKにどのように対応しているかを確認することをお勧めします。例えば、Windowsの特定のイベントに注目しているアナリティクスがあるとします。このアナリティクスのカバレッジを判断するには、Windows ATT&CK Logging Cheat SheetなどでイベントIDを調べることができます。また、ATT&CKのウェブサイトを利用して分析を行うこともできます。下図は、ポート22の検出を検索した例ですが、これは「Commonly Used Port ATT&CK technique」に表示されています。

ATT&CK site search for port 22

もう一つの重要な点は、テクニックと一緒に掲載されているグループやソフトウェアの例です。これらは、敵対者がテクニックを使用する際の手順や具体的な方法を示しています。多くの場合、これらの例は、既存の分析でカバーされているか否かにかかわらず、テクニックのバリエーションを示しており、テクニックをどれだけカバーしているかという信頼性評価に織り込む必要があります。

Examples section of Windows Admin Shares

分析結果を見るだけでなく、ツールの分析にも着手しましょう。そのためには、各ツールのヒートマップを作成し、次のような質問を繰り返し行うことをお勧めします。
  • ツールはどこで実行されますか?ツールがどこで実行されているか(例えば、境界や各エンドポイント)によって、特定の戦術でうまくいったり、うまくいかなかったりします。
  • ツールはどのように検出しますか?既知の悪い指標の静的なセットを使用していますか?それとも、何か行動的なことをしているのでしょうか?
  • そのツールはどのようなデータソースを監視していますか?ツールが監視しているデータソースを知ることで、どのようなテクニックを検出するかを推測することができます。

これらの質問に答えるのは大変です。すべてのベンダーがこの種の情報を公開しているわけではありませんし、探してもマーケティング資料になってしまうことがよくあります。このような質問に答えるのは大変です。

カバレッジの最終的なヒートマップを作成するには、ツールと分析のヒートマップをすべて集約し、各手法で最も高いカバレッジを記録します。これができたら、次は改善に向けて動き出します。最初のステップとして、前述の分析開発プロセスのより高度なバージョンをお勧めします。

  1. 短期的に注力したい優先度の高い技術のリストを作成する。
  2. 重点的に取り組む技術の分析を始めるために、適切なデータを集めていることを確認する。
  3. アナリティクスの作成とカバレッジチャートの更新を開始する。

現在の補償内容から始めて、アナリティクスを追加し、それに応じて補償内容を更新していきます。

また、ツールのアップグレードも必要かもしれません。ドキュメントを分析する際には、カバー率を高めるために使用できる可能性のあるオプションのモジュールを追跡してください。そのようなモジュールが見つかった場合には、それをネットワーク上で有効にするために必要なものを調べ、そのモジュールが提供するカバー率とのバランスを取ってください。ツールの追加モジュールが見つからない場合は、代替のデータソースとして利用することもできます。例えば、各エンドポイントにSysmonをインストールすることはできないかもしれないが、既存のソフトウェアが、他の方法ではアクセスできないような関連するログを転送できるかもしれない。

次のレベルへの卒業:これらの変更を実施してカバレッジを向上させたら、次のステップとして、敵対者のエミュレーション、特にアトミックテストを導入します。新しい分析手法を試作するたびに、それに対応するアトミックテストを実行して、その結果を確認します。捕まえられれば上出来です。捕まえられなかった場合は、何を見逃したのかを確認し、それに応じて分析手法を改良します。このプロセスの詳細については、当社の論文「ATT&CKベースの分析でサイバー脅威を発見する」を参照してください。

Level 3

より高度なチームの場合、評価を強化するための素晴らしい方法として、ミティゲーションを含めることができます。これにより、ツールやアナリティクスの検出内容だけを見るのではなく、SOC全体を見て評価を行うことができます。

技術をどのように緩和しているかを確認する良い方法は、SOC の各ポリシー、予防ツール、セキュリティコントロールを確認し、それらが影響を与える可能性のある ATT&CK 技術にマッピングして、それらの技術をカバー範囲のヒートマップに追加することです。最近、ミティゲーションを再構築したことにより、各ミティゲーションを見て、それがマッピングされている技術を確認することができます。ミティゲーションが適用された技術の例としては、以下のようなものがあります。

ブルートフォース(左)とWindows Admin Shares(右)の緩和策。

アセスメントの範囲を広げるもう一つの方法は、SOCで働いている人にインタビューしたり、非公式に話を聞いたりすることです。これは、ツールがどのように使用されているかをよりよく理解するのに役立つだけでなく、他の方法では考えられないギャップや強みを明らかにすることができます。例えば、以下のような質問が考えられます。

  • 最もよく使うツールは何ですか?その長所と短所は何ですか?
  • 見ることができないデータソースで、見ることができたらいいなと思うものは何ですか?
  • 検知の観点から見た、あなたの最大の強みと弱みはどこですか?

これらの質問への回答は、先に作成したヒートマップを補強するのに役立ちます。

例:以前、ATT&CK関連の機能を多く持つツールを見つけたが、人事はWindowsのレジストリを監視するためだけに使用している場合、そのツールのヒートマップを修正して、使用方法をよりよく反映させる必要があります。

同僚と話しながら、以前に作成したツールのヒートマップを見てみましょう。自分が使っているツールのカバレッジにまだ満足していないのであれば、新しいツールを評価する必要があるかもしれません。新しいツールを検討する際には、それぞれのツールのカバレッジのヒートマップを作成し、そのツールを追加することでどのようにカバレッジが向上するかを確認します。

ヒント:特にリソースに余裕がある場合は、代表的なテスト環境を立ち上げて、そのツールをライブでテストし、うまくいったところ、うまくいかなかったところ、そのツールを追加した場合に既存のカバレッジにどのような影響があるかなどを記録することができます。

最後に、より多くのミティゲーションを導入することで、ツールやアナリティクスへの依存度を下げることができるかもしれません。ATT&CKに掲載されているミティゲーションを見て、実際に導入できるかどうかを判断します。このプロセスの一環として、検出ヒートマップを参照してください。検出がうまくいっている技術を妨げる高コストの緩和策があれば、それは良いトレードオフではないかもしれません。一方で、分析結果を書くのに苦労している技術に対して、低コストの緩和策があれば、それを実施することでリソースを有効に活用できるかもしれません。

ヒント: ミティゲーションのために検出を取り除くことを検討する際には、可視性が失われる可能性を常に考慮してください。ミティゲーションやコントロールがバイパスされる可能性がある場合には、それらのイベントが見逃される可能性が低くなるように、ある程度の可視性を確保してください。検知とミティゲーションは、どちらも効果的なカバレッジのためのツールとして使用する必要があります。

クロージング: アセスメントとエンジニアリングの関係

アセスメントを行うことで、現在のカバレッジがどこにあるのかを理解し、それを脅威インテリジェンスで補強してギャップを優先し、アナリティクスを書くことで既存の防御を調整することができます。

長期的には、毎週、あるいは毎月、アセスメントを実施することは想定していません。その代わりに、前回のアセスメントの内容を記録し、新しい情報を得るたびに更新し、定期的に敵のエミュレーション演習を行って結果をスポットチェックする必要があります。時間の経過とともに、ネットワークや収集された情報に変化が生じ、以前にテストした防御の効果が低下することがあります。ATT&CK を活用して実際の脅威に対する防御力を示すことで、防御態勢の理解を深め、改善の優先順位を決めることができます。

ATT&CKのユースケースを可視化

スマホリプレース~さらばXPERIA~


現在使っているスマホが購入から3~4年経過し、リプレースを検討している。

現在使用しているのは「docomo」と落書きの入ったXPERIA X Compact(SO-02J)を使っている。

実はスマホが世の中に登場した時からずっとXPERIAを愛用している。

XPERIAは寿命が近づいてくると出てくる傾向みたいのがあって、

まずSDカードが突然認識できなくなる。

その後、しばらくするとOSの挙動がおかしくなる。

先日SDカードが突然認識できなくなり、いよいよ後継を検討しなければならなくなったというわけである。

回線はIIJ mioを使っているため、XPERIAは使いたいものの、「docomo」とか「au」とか「Softbank」とか落書きの入った機種は本当は使いたくない。

そのため、海外モデルも検討してみたのだが、海外モデルはおサイフケータイが使えない。

一時期Google Payとかで対応できるんじゃないかと思ったが、いろいろ調べるとそうではないことが分かった。

おサイフケータイの件は対応するNFCの規格と関連する。

NFCの規格にはTypeA、TypeB、TypeFの3種類ある。

一般的に搭載されているのはTypeA/Bであり、TypeFというのが所謂おサイフケータイ対応の規格となる。

そもそもTypeFのFはFelicaからきているようで、Suicaの様に通勤ラッシュでも問題なく使えるように処理が高速化された規格となっており、その分コストも高くつく結果となっている。

海外ではSuicaのような高速な処理を求められるシーンがないため、必然的にコストアップの要因になるTypeFは搭載されない。

結局ガラパゴス仕様で日本国内向けのXPERIAにしか搭載されないというわけである。

で、国内で販売されるXPERIAを検討するのだが、困ったことが起きた。


何なんだ、この縦横比が大きく崩れた無駄な縦長画面は・・・

ダサイ

ソニーは一般人が理解できない際どいエリアを攻めに行ってしまったのだろうか?

正直XPERIAに欲しい機種がなく、しばらく悩んでいたところ、なんとGoogleから希望する画面サイズ感で、しかも手ごろな値段でスマホ「Google Pixel 4a」が発売されていることが分かった。

更にしばらく悩んだ結果、Googleストアで決済する運びとなった。

XPERIA以外のスマホを使うのは何気に人生初の経験である。

とりあえず後継のスマホが決まったことに安堵するとともに、ソニーのモノ作りがおかしな方向に進んでいないか若干気になる今日この頃。

さらばXPERIA。ありがとうXPERIA。

ランサムウェアREvilの中の人とRecorded Futureとのインタビュー / ‘I scrounged through the trash heaps… now I’m a millionaire:’ An interview with REvil’s Unknown(転載)


ランサムウェアREvilの中の人とRecorded Futureとのインタビュー ‘I scrounged through the trash heaps… now I’m a millionaire:’ An interview with REvil’s Unknown therecord.media/i-scrounged-th…: ランサムウェアREvilの中の人とRecorded Futureとのインタビュー
‘I scrounged through the trash heaps… now I’m a millionaire:’ An interview with REvil’s Unknown therecord.media/i-scrounged-th…

インターネットに晒されている機器を調べるサイト【ZoomEye】



こちらはZoomeyeでの調査。実はヘッダにこうやってバージョンが載ってきてしまうようで、この情報を分析すればターゲットを絞れる可能性があります。もっとも、脆弱性自体は1年前…orz:

こちらはZoomeyeでの調査。実はヘッダにこうやってバージョンが載ってきてしまうようで、この情報を分析すればターゲットを絞れる可能性があります。もっとも、脆弱性自体は1年前…orz

EwfSMBrVoAIpTdZ.png:large

世界に羽ばたく”国際信州学院大学”~Le jour du poisson d'avril aujourd'hui~


 国際信州学院大学をご存じだろうか?

長野県にある大学とのことで、しっかりとしたWebサイトも作られている。最近開校した大学だろうか?

学長の言葉がなかなか素晴らしい。

JNSAの損害賠償額算出式は正しいのか?~実際の判例をもとに検証してみる~


 企業が情報漏洩を起こした際、JNSAの損害賠償額算出式を用いた想定損害賠償額を算出しているが、これって妥当なのだろうか?

先日、とある判例の話を聞けたので、それを基に検証してみたい。

【インシデント概要】
不正アクセスによる個人情報流出

 -最大1万6798件の個人情報、うち7316件はクレジットカード情報

・流出した情報(赤字個所は特に損害賠償額に大きく響く項目)

-名前

-住所

-電話番後

-メールアドレス

-クレジットカード番号(番号、名義、有効期限セキュリティコード含む)

-性別

-生年月日

-パスワード

JNSAの損害賠償額算出式を用いた想定損害賠償額

・カード流出に関わる1件当たりの想定損害賠償額:78,000円
 ⇒7,316件なので、計570,648,000円(約5.7億円)


【流出企業における実際の損害額】

・SQLインジェクションを抱えたポンコツシステムの開発費:約2,100万円

・顧客への謝罪費用(クオカード):約1,900万円

・顧客からの苦情処理費用:約500万円

・調査費用(主にフォレンジック):約400万円

・営業損失:約6,000万円

・その他:約50万円

------------------------------

計約1.1億円


ん~。損害賠償額算出式の方がかなり上振れているな。。。

とはいえ、クレジットカードの有効期限とセキュリティコードまで流出しているので、この金額で済んだのは不幸中の幸いともいえるかもしれない。

裁判になるといろいろと細かいことが明らかになるので、興味深い。

ちなみに判例の詳細はこちら(バックアップ)