暗号通貨とトークン自体をさまざまな方法で処理することは可能ですが、すべてのセキュリティガードは、不正に企業の機器で実行された場合、マイニングに対して否定的な態度をとります。 外部の侵入者がメインのマルウェアモジュールの負荷にマイナーを配布し、システムプロセスの名前（C：\ Windows \ Sys \ taskmgr.exeなど）で非表示にした場合、多くのインシデントを記録および調査しました。ネットワークエクスプロイト、Psexecおよびその類似物、そしてもちろん悪意のあるJavascriptのアカウント。
しかし、侵入者に加えて、侵入者がいます。 そしてほとんどの場合、彼は自分が何をしているのか、罰せられないようにトラックを隠す方法をよく知っています。 そのようなケースの1つに調査を依頼しました。
場合によっては、誰がマイナーを起動したかを理解するためにSIEMログを調べるだけで十分です。次のスクリーンショットは、サーバーユーザーのデスクトップでマイナーの実行可能ファイルが解凍されたことを示しています。
仮説0。ファイルがデスクトップに展開されるため、従業員は意識的にこれを行いました。 これによりマルウェアが作成される可能性は最小限です。
この仮説の確認は非常に簡単です。ユーザーの職場のウイルス対策ログを調べるだけです。 確かに、これまでと同じルールが\ Downloadsフォルダー内のアーカイブに対して機能していました。
ただし、SIEMの雑誌を見ると、常にではありませんが、企業のセキュリティポリシーに違反しているのは誰なのかを明らかにすることは可能です。 そのような場合、インシデントはSolar JSOC CERTに報告されます。
ビジネスへ
Solar JSOCサービス提供の一部として、より高いレベルのエンティティ、つまり監視シナリオがあります。 それは、どのインシデントを特定することにコミットしており、さまざまな監視ラインがそれらにどのように対応すべきかを説明しています。 当然、すべての顧客は異なり、それぞれが定期的にレビューおよび変更される独自のシナリオのセットを持っています。
ある午後、同僚は主要なシナリオと主要なクライアント、つまり鉱業活動の検出を結び付けました。 SIEMにルールセットが含まれてから10秒後、複数のDNSクエリをマイニングプールの1つのアドレスに修正し始めました。
Solar JSOCのアナリストは、クライアントに「潜在的に望ましくないアクティビティ」を通知し、クライアントはファイアウォールとプロキシサーバーの呼び出しをブロックしました。 私たちはきちんと働いて、すべてがうまくいくようで、先に進むことができます。 しかし同時に、アナリストは、マイニングが32の異なるIPアドレスから実行されたという事実にも注意を喚起しました。これは、ドキュメントによると、ハイパーバイザーです（そしてその容量は相当なものです）。 インシデントの詳細な調査を要求した顧客にすぐに通知しました。
ケースがJSOC CERTに転送されるとすぐに、私たちはすぐにデジタル証拠（ハードディスク、RAMなどのコピー）の収集を開始しました。ここでは、調査の邪魔になる2つの不快な状況がありました。
- マイニングアクティビティが実行されたネットワークセグメントは、SIEMに接続されていません（インフラストラクチャのカバレッジが限られているため）。
- クライアントはハイパーバイザーにリモートアクセスできませんでした。ドキュメントによると、 2か月前にスクラップに償却されていたためです。
最初に、攻撃者を「ライブ」でキャッチするためにマイニングプールのドメイン名のブロックを無効にすることを提案しましたが、ブロックを無効にした後、アクティビティは再開しませんでした。 どうやら、攻撃者は彼らが彼の活動について学んだことに気づき、鉱夫を止めました。
仮説1。侵入者は自分の侵入者である可能性があります。
データセンターに行き、その場でデータを取得します。 空のラックと消磁されたハードドライブのダンプが表示されます。 データセンターの従業員も定期的に働いていました。ハイパーバイザーを分解するときは、情報セキュリティのためにディスクを消磁する必要があります。これは実際に2か月前に行われました。
仮説2。データセンターの従業員が事件に関与しています。
その結果、ターゲットサーバーがなく、ドメインコントローラーのログがほつれている（このセグメントはSIEMに接続されていない）、セグメントからのインターネットアクセスがプロキシされていない、ネットフローがまったくないなどの不快な状況があります...私たちが持っているものを覚えています。 そして、DNSサーバーのログのみがありました...
非常に大きなログを分析する必要がある場合、各インシデント対応スペシャリストは「his」ユーティリティを使用します。
- 誰かがイベントログエクスプローラーを使用しています。
- 誰かがすべてをElastic / Kibanaにエクスポートしています。
- 誰かがcsvにエクスポートしてから、コマンドラインでsort-itとgrepを直接エクスポートします。
上記のすべてを使用しますが、この場合、古き良きExcelで行われた統計分析は最も鮮明でした。つまり、ピボットテーブルは、そのようなレコードの数百万回を数回のクリックに変換します。
HPE ArcSightアップロードの例
そのようなテーブルに：
特定のIPアドレス（水平）からの1日あたりのDNSクエリ数（垂直）
次に、アクティビティが観察されたセルを強調表示し、マイニングプールのドメイン名にフィルターを設定し、明らかなノイズを除去し、他の興味深いドメインにフォーマットを追加します。その結果、いくつかのパターンを選択できるビジュアルテーブルを取得できます彼らは攻撃者がどのように行動したかを示唆しています：
明確な書式設定のあるピボットテーブル
ほとんどのインシデントは同じパターンで始まります：
- 最初に、サーバーはWindowsシステムに固有のDNSクエリを送信します（NTPサーバーへのクエリとtelecommand.telemetry.microsoft [。] Comのようなテレメトリー）。
- アクティビティは1週間、1日間停止し、時にはまったく停止しません。
- サーバーはUbuntu固有のリクエスト（ntp.ubuntu [。] Com、security.ubuntu [。] Com、us.archive.ubuntu [。] Comなど）の送信を開始します。
仮説3。攻撃者は、ハイパーバイザーが以前持っていたのと同じIPでUbuntu仮想マシンを持ち上げました。
マイニングの開始直前に、ホストの半数以上がgoogle [。] Comに移行し、すぐにdownload.minergate [。] Comに移行しました。 その後、これらの各ホストは、同じホストに対して別のネットワークセグメントから逆DNSレコードを2、3回要求しました。
ノード逆引きDNSクエリ
仮説4。仮想マシンを作成した後、攻撃者はその上でブラウザを開き、Googleにアクセスし、マイナーのダウンロードページを見つけてダウンロードし、「ノードポイント」に移動しました。
この仮説の確認の1つは、一部のサーバーがIPアドレスに似たドメイン名を要求したが、エラーが発生したという事実です。攻撃者が誤ってコンマとピリオドを混同したかのようでした。
攻撃者がノードポイントにアクセス中にエラーが発生しました
幸いなことに、ノードポイントに最も近いドメインコントローラーはSIEMに接続されていたため、誰がどのアカウントでログインしたかを見つけることができました。
節点ですべてのアカウントを認証しようとする回数。 明白な理由のための唯一のアカウントは上書きされます。
合計：
| いや
| 仮説
| 検証ステータス
|
| 1。
| 侵入者は自分の侵入者である可能性があります。
| 確認済み
|
| 2。
| データセンターの従業員がインシデントに関与しています。
| 反証
|
| 3。
| 攻撃者は、ハイパーバイザーが以前持っていたのと同じIPを持つUbuntu仮想マシンを手に入れました。
| 確認済み
|
| 4。
| 仮想マシンを作成した後、攻撃者はその上でブラウザを開き、Googleにアクセスし、マイナーのダウンロードページを見つけてロードし、「ノードポイント」に移動しました。
| 確認済み
|
おわりに
そのため、調査が始まった時点では、ほとんど何もありませんでした。 すべてのドライブは消磁され、雑誌はほつれ、攻撃者は自分が開けられたことを知り、トラックをクリアしました。 ただし、ご覧のとおり、情報源の不足は必ずしも問題が悪いことを意味するわけではありません。 システムがどのように機能するかを十分に理解し、入力データを非自明な方法で見ようとするだけで十分です-情報の再生、ねじれ、解釈オプションの検索。 そして、文字通り標準的なオフィススイートのみを使用して、高価なフォレンジックツールやAPTスキャナーなしで調査を正常に実行できます。 そして、これはフォレンジックの本質です。情報セキュリティインシデントを調査するために使用できるツールはそれほど重要ではありません。主なことは、システムの原則を深く理解し、細部に注意を払うことです。