Linuxディスクイメージのフォレンジック分析は、多くの場合、侵害が発生したかどうかを判断するためのインシデント対応の一部です。 Linuxフォレンジックは、MicrosoftWindowsフォレンジックとは異なり魅力的な世界です。この記事では、侵害された可能性のあるLinuxシステムのディスクイメージを分析して、インシデントの誰が、何を、いつ、どこで、なぜ、どのように行ったかを判断し、イベントとファイルシステムのタイムラインを作成します。最後に、ディスクイメージから関心のあるアーティファクトを抽出します。
このチュートリアルでは、いくつかの新しいツールといくつかの古いツールをクリエイティブで新しい方法で使用して、ディスクイメージのフォレンジック分析を実行します。
シナリオ
その他のLinuxリソース
- Linuxコマンドのチートシート
- 高度なLinuxコマンドのチートシート
- 無料のオンラインコース：RHELの技術概要
- Linuxネットワーキングのチートシート
- SELinuxチートシート
- Linuxの一般的なコマンドのチートシート
- Linuxコンテナとは何ですか？
- 最新のLinux記事
Premiere Fabrication Engineering（PFE）は、pfe1という名前の会社のメインサーバーに関連するインシデントまたは侵害があったと疑っています。彼らは、サーバーがインシデントに関与していた可能性があり、3月1日から3月の終わりまでの間に侵害された可能性があると考えています。彼らは、サーバーが危険にさらされてインシデントに関与していないかどうかを調査するために、フォレンジック審査官として私のサービスを利用しました。調査により、誰が、何を、いつ、どこで、なぜ、どのように侵害の可能性があるかが判断されます。さらに、PFEは、サーバーのセキュリティ対策を強化するための推奨事項を要求しました。
ディスクイメージ
サーバーのフォレンジック分析を行うために、PFEにUSBドライブ上のpfe1のフォレンジックディスクイメージを送信するように依頼します。彼らは同意し、「USBは郵送されている」と言います。 USBドライブが届き、中身を調べ始めます。フォレンジック分析を実行するために、SANS SIFTディストリビューションを実行している仮想マシン（VM）を使用します。 SIFTワークステーションは、さまざまな設定で詳細なデジタルフォレンジック検査を実行するように設計された、無料のオープンソースのインシデント対応およびフォレンジックツールのグループです。 SIFTにはさまざまなフォレンジックツールがあります。必要なツールがない場合は、Ubuntuベースのディストリビューションであるため、問題なくインストールできます。
調べてみると、USBにはディスクイメージが含まれておらず、PFEのハイブリッドクラウドからのVMDKファイルであるVMwareESXホストファイルのコピーが含まれていることがわかりました。これは私が期待していたものではありませんでした。いくつかのオプションがあります：
- PFEに連絡して、彼らに何を期待しているのかをより明確にすることができます。このようなエンゲージメントの早い段階では、それが最善の方法ではない可能性があります。
- VMDKファイルをVMPlayerなどの仮想化ツールにロードし、ネイティブLinuxプログラムを使用してライブVMとして実行し、フォレンジック分析を実行できます。これを行わない理由は少なくとも3つあります。まず、VMDKファイルをライブシステムとして実行すると、ファイルとファイルコンテンツのタイムスタンプが変更されます。次に、サーバーが危険にさらされていると考えられるため、VMDKファイルシステムのすべてのファイルとプログラムが危険にさらされていると見なす必要があります。第三に、侵害されたシステムでネイティブプログラムを使用してフォレンジック分析を行うと、予期しない結果が生じる可能性があります。
- VMDKファイルを分析するには、VMDKファイルに保存されているデータにアクセスするためのツールを含むlibvmdk-utilsパッケージを使用できます。
- ただし、より良いアプローチは、VMDKファイル形式をRAW形式に変換することです。これにより、ディスクイメージ内のファイルでSIFTディストリビューションのさまざまなツールを簡単に実行できるようになります。
VMDKからRAW形式に変換するには、qemu-imgユーティリティを使用します。このユーティリティを使用すると、画像をオフラインで作成、変換、および変更できます。次の図は、VMDK形式をRAW形式に変換するコマンドを示しています。
次に、ディスクイメージからパーティションテーブルを一覧表示し、mmlsユーティリティを使用して各パーティションの開始位置（セクター）に関する情報を取得する必要があります。このユーティリティは、パーティションテーブルやディスクラベルなど、ボリュームシステム内のパーティションのレイアウトを表示します。次に、開始セクターを使用し、ファイルシステムに関連付けられた詳細を表示するfsstatユーティリティを使用してファイルシステムに関連付けられた詳細を照会します。以下の図は、mmlsを示しています。 およびfsstat 動作中のコマンド。
mmlsからいくつかの興味深いことを学びます 出力：Linuxプライマリパーティションはセクター2048で始まり、サイズは約8ギガバイトです。 DOSパーティション（おそらくブートパーティション）のサイズは約8メガバイトです。最後に、約8ギガバイトのスワップパーティションがあります。
fsstatを実行しています ファイルシステムのタイプ、データがファイルシステムに最後に書き込まれた時刻、ファイルシステムが完全にアンマウントされたかどうか、ファイルシステムがマウントされた場所など、パーティションに関する多くの有用な情報を教えてくれます。
パーティションをマウントして分析を開始する準備ができました。これを行うには、指定されたrawイメージのパーティションテーブルを読み取り、検出されたパーティションセグメント上にデバイスマップを作成する必要があります。 mmlsからの情報を使って手作業でこれを行うことができます およびfsstat -または、kpartxを使用してそれを行うことができます。
オプションを使用して読み取り専用マッピングを作成します（-r ）、パーティションマッピングを追加します（-a ）、詳細な出力を提供します（-v ）。 loop0p1 /dev/mapperの下にあるデバイスファイルの名前です。 パーティションへのアクセスに使用できます。マウントするには、次のコマンドを実行します：
$ mount -o ro -o loop=/dev/mapper/loop0p1 pf1.raw /mnt
パーティションを読み取り専用としてマウントしていることに注意してください（-o ro ）偶発的な汚染を防ぐため。
ディスクをマウントした後、タイムラインを作成してフォレンジック分析と調査を開始します。一部の法医学検査官は、タイムラインの作成を信じていません。代わりに、パーティションがマウントされると、ファイルシステムを這い回り、調査に関連する可能性のあるアーティファクトを探します。私はこれらの法医学検査官に「クリーパー」というラベルを付けます。これは法医学的に調査する1つの方法ですが、再現性にはほど遠いものであり、エラーが発生しやすく、貴重な証拠を見逃す可能性があります。
タイムラインの作成は、MAC（変更、アクセス、変更）タイムエビデンスと呼ばれる、人間が読める形式で変更、アクセス、変更、および作成されたファイルに関する有用な情報が含まれているため、重要なステップだと思います。このアクティビティは、特定の時間とイベントが発生した順序を特定するのに役立ちます。
Linuxファイルシステムに関する注意事項
ext2やext3などのLinuxファイルシステムには、ファイルの作成/生年月日のタイムスタンプがありません。作成タイムスタンプはext4で導入されました。本フォレンジックディスカバリー （第1版）DanFarmerとWietseVenemaによるさまざまなタイムスタンプの概要。
- 最終変更時刻： ディレクトリの場合、これがエントリが追加、名前変更、または削除された最後の時間です。他の種類のファイルの場合、ファイルが最後に書き込まれたのはこれです。
- 最終アクセス（読み取り）時間： ディレクトリの場合、これが最後に検索された時間です。他の種類のファイルの場合、ファイルが最後に読み取られたのはこれです。
- 最後のステータス変更： ステータスの変更の例としては、所有者の変更、アクセス許可の変更、ハードリンクカウントの変更、または任意のMAC時間の明示的な変更があります。
- 削除時間： ext2とext3は、ファイルが削除された時刻を
dtimeに記録します。 タイムスタンプですが、すべてのツールがタイムスタンプをサポートしているわけではありません。 - 作成時間： ext4fsは、ファイルが作成された時刻を
crtimeに記録します タイムスタンプですが、すべてのツールがタイムスタンプをサポートしているわけではありません。
さまざまなタイムスタンプが、iノードに含まれるメタデータに格納されます。 iノードは、Windowsの世界のMFTエントリ番号に似ています。 Linuxシステムでファイルメタデータを読み取る1つの方法は、最初にコマンドls -i fileを使用してiノード番号を取得することです。 次に、istatを使用します パーティションデバイスに対して、iノード番号を指定します。これにより、タイムスタンプ、ファイルサイズ、所有者のグループとユーザーID、権限、実際のデータを含むブロックなど、さまざまなメタデータ属性が表示されます。
スーパータイムラインの作成
次のステップは、log2timeline/plasoを使用してスーパータイムラインを作成することです。 Plasoは、最初にKristinn Gudjonssonによって作成され、他の人によって拡張されたPerlベースのlog2timelineツールをPythonベースで書き直したものです。 log2timelineを使用してスーパータイムラインを作成するのは簡単ですが、解釈は困難です。最新バージョンのplasoエンジンは、ext4だけでなく、syslogメッセージ、監査、utmpなどのさまざまなタイプのアーティファクトを解析できます。
スーパータイムラインを作成するには、マウントされたディスクフォルダーに対してlog2timelineを起動し、Linuxパーサーを使用します。このプロセスには時間がかかります。終了したら、plasoデータベース形式のさまざまなアーティファクトを含むタイムラインがあり、psort.pyを使用できます。 plasoデータベースを任意の数の異なる出力形式に変換します。 psort.pyの出力形式を確認するには サポートしている場合は、psort -o listと入力します 。 psort.pyを使用しました Excel形式のスーパータイムラインを作成します。次の図は、この操作を実行する手順の概要を示しています。
（注：画像から余分な線が削除されています）
スーパータイムラインをスプレッドシートプログラムにインポートして、表示、並べ替え、検索を簡単にします。スプレッドシートプログラムでスーパータイムラインを表示できますが、MySQLやElasticsearchなどの実際のデータベースで操作する方が簡単です。 2番目のスーパータイムラインを作成し、psort.pyからElasticsearchインスタンスに直接ディスパッチします 。 Elasticsearchによってスーパータイムラインのインデックスが作成されると、Kibanaを使用してデータを視覚化および分析できます。
Elasticsearch/Kibanaによる調査
ファレル軍曹が言ったように、「準備と規律を通して、私たちは運命の達人です。」分析中は、忍耐強く細心の注意を払い、クリーパーにならないようにすることが重要です。スーパータイムライン分析に役立つ1つのことは、インシデントがいつ発生したかを把握することです。この場合（しゃれを意図したもの）、クライアントは事件が3月に起こった可能性があると言います。私はまだクライアントが時間枠について間違っている可能性を考えています。この情報を武器に、スーパータイムラインのタイムフレームを短縮して絞り込みます。事件の想定日と「一時的に近い」関心のあるアーティファクトを探しています。目標は、さまざまなアーティファクトに基づいて起こったことを再現することです。
スーパータイムラインの範囲を狭めるために、設定したElasticsearch/Kibanaインスタンスを使用します。 Kibanaを使用すると、関心のあるフォレンジックイベントを表示して相互に関連付けるために、複雑なダッシュボードをいくつでも設定できますが、このレベルの複雑さは避けたいと思います。代わりに、表示する対象のインデックスを選択し、日付ごとのアクティビティの棒グラフを作成します。
次のステップは、チャートの最後にある大きなバーを展開することです：
3月5日に大きなバーがあります。そのバーを展開して、その特定の日付のアクティビティを確認します：
スーパータイムラインからのログファイルアクティビティを見ると、このアクティビティはソフトウェアのインストール/アップグレードによるものであることがわかります。この分野の活動にはほとんど何も見つかりません。
Kibanaに戻って、システム上の最後の一連のアクティビティを確認し、ログでこれを見つけます：
システムでの最後のアクティビティの1つは、ユーザーjohnがxingyiquanという名前のディレクトリからプログラムをインストールしたことです。形意拳は、カンフーや太極拳に似た中国武術のスタイルです。ユーザーjohnが自分のユーザーアカウントから会社のサーバーに武道プログラムをインストールするのは奇妙に思えます。 Kibanaの検索機能を使用して、ログファイルでxingyiquanの他のインスタンスを検索します。 3月5日、3月9日、3月12日に、形意拳を取り巻く3つの活動期間を見つけました。
次に、最近のログエントリを確認します。私は3月5日から始めて、FirefoxブラウザとGoogle検索エンジンを使用したxingyiquanという名前のルートキットのインターネット検索の証拠を見つけました。 Google検索では、packetstormsecurity.comにそのようなルートキットの存在が見つかりました。次に、ブラウザはpacketstormsecurity.comにアクセスし、xingyiquan.tar.gzという名前のファイルをダウンロードしました。 そのサイトからユーザーjohnのダウンロードディレクトリに移動します。
ユーザーjohnがルートキットを検索するためにgoogle.comにアクセスし、次にルートキットをダウンロードするためにpacketstormsecurity.comにアクセスしたように見えますが、これらのログエントリは検索とダウンロードの背後にいるユーザーを示していません。これについてさらに詳しく調べる必要があります。
Firefoxブラウザは、履歴情報を.mozillaの下のSQLiteデータベースに保持します。 places.sqliteという名前のファイル内のユーザーのホームディレクトリ（つまり、ユーザーjohn）内のディレクトリ 。データベース内の情報を表示するには、sqlitebrowserというプログラムを使用します。これは、ユーザーがSQLiteデータベースにドリルダウンして、そこに保存されているレコードを表示できるようにするGUIアプリケーションです。 sqlitebrowserを起動し、places.sqliteをインポートしました .mozillaから ユーザーjohnのホームディレクトリの下のディレクトリ。結果を以下に示します。
右端の列の数字は、左側のアクティビティのタイムスタンプです。合同のテストとして、タイムスタンプ1425614413880000を変換しました 人間の時間に、2015年3月5日午後8時13分880秒を取得しました。これは、2015年3月5日のKibanaからの20：00：00.000の時間と密接に一致します。ユーザーjohnがxingyiquanという名前のルートキットを検索し、packetstormsecurity.comからxingyiquan.tar.gzという名前のファイルをダウンロードしたことは確かに言えます。 ユーザーjohnのダウンロードディレクトリに移動します。
MySQLによる調査
この時点で、スーパータイムラインをMySQLデータベースにインポートして、Elasticsearch/Kibanaだけで許可されるよりもデータの検索と操作の柔軟性を高めることにしました。
xingyiquanルートキットの構築
plasoデータベースから作成したスーパータイムラインをMySQLデータベースにロードします。 Elasticsearch / Kibanaでの作業から、ユーザーjohnがルートキットxingyiquan.tar.gzをダウンロードしたことがわかりました。 packetstormsecurity.comからダウンロードディレクトリへ。 MySQLタイムラインデータベースからのダウンロードアクティビティの証拠は次のとおりです。
ルートキットがダウンロードされた直後に、tar.gzからのソース アーカイブが抽出されました。
3月9日、悪意のある攻撃者がMoreプログラムを使用してルートキットのREADMEファイルを読み取り、ルートキットをコンパイルしてインストールするまで、ルートキットには何も行われませんでした。
コマンド履歴
bashを持つすべてのユーザーの履歴をpfe1にロードします コマンド履歴をMySQLデータベースのテーブルに追加します。履歴が読み込まれると、次のようなクエリを使用して簡単に表示できます。
select * from histories order by recno; 特定のユーザーの履歴を取得するには、次のようなクエリを使用します：
select historyCommand from histories where historyFilename like '%<username>%' order by recno;
ユーザーjohnのbashからいくつかの興味深いコマンドを見つけました 歴史。つまり、ユーザーjohnはjohnnアカウントを作成し、削除し、再度作成し、/bin/trueをコピーしました。 /bin/falseへ 、whoopsieアカウントとlightdmアカウントにパスワードを与え、/bin/bashをコピーしました /bin/falseへ 、パスワードとグループファイルを編集し、ユーザーjohnnのホームディレクトリをjohnnから移動しました .johnnへ 、（隠しディレクトリにします）、sedを使用してパスワードファイルを変更しました
次に、bashを見てみましょう。 ユーザーjohnnのコマンド履歴。異常な活動は見られませんでした。
ユーザーjohnが/bin/bashをコピーしたことに注意してください /bin/falseへ 、これらのファイルのサイズをチェックし、ファイルのMD5ハッシュを取得することで、これが正しいかどうかをテストします。以下に示すように、ファイルサイズとMD5ハッシュは同じです。したがって、ファイルは同じです。
成功したログインと失敗したログインの調査
「いつ」の質問の一部に答えるために、ログイン、ログアウト、システムの起動、およびシャットダウンに関するデータを含むログファイルをMySQLデータベースのテーブルにロードします。次のような単純なクエリを使用する：
select * from logins order by start 次のアクティビティが見つかりました：
この図から、ユーザーjohnがIPアドレス192.168.56.1からpfe1にログインしていることがわかります。 。 5分後、ユーザーjohnnは同じIPアドレスからpfe1にログインしました。ユーザーlightdmによる2回のログインは、4分後と1分後に続き、ユーザーjohnnは1分以内にログインしました。その後、pfe1が再起動されました。
失敗したログインを見ると、次のアクティビティが見つかります：
繰り返しますが、ユーザーlightdmはIPアドレス192.168.56.1からpfe1にログインしようとしました 。偽のアカウントがpfe1にログインしていることを考慮して、PFEに対する私の推奨事項の1つは、IPアドレス192.168.56.1でシステムをチェックすることです。 妥協の証拠のために。
ログファイルの調査
ログインの成功と失敗のこの分析は、イベントがいつ発生したかについての貴重な情報を提供します。 pfe1のログファイル、特に/var/log/auth*の認証および承認アクティビティの調査に注意を向けます。 。 pfe1のすべてのログファイルをMySQLデータベーステーブルにロードし、次のようなクエリを使用します：
select logentry from logs where logfilename like '%auth%' order by recno;
それをファイルに保存します。そのファイルをお気に入りのエディターで開き、192.168.56.1を検索します 。アクティビティのセクションは次のとおりです。
このセクションは、ユーザーjohnがIPアドレス192.168.56.1からログインしたことを示しています。 johnnアカウントを作成し、johnnアカウントを削除して、再度作成しました。次に、ユーザーjohnnがIPアドレス192.168.56.1からpfe1にログインしました。 。次に、ユーザーjohnnは、suを使用してユーザーwhoopsieになろうとしました。 失敗したコマンド。次に、ユーザーwhoopsieのパスワードが変更されました。次に、ユーザーjohnnがsuを使用してユーザーlightdmになろうとしました コマンド、これも失敗しました。これは、図21および22に示されているアクティビティと相関しています。
調査の結論
- ユーザーjohnは、xingyiquanという名前のルートキットを検索、ダウンロード、コンパイルして、サーバーpfe1にインストールしました。 xingyiquanルートキットは、プロセス、ファイル、ディレクトリ、プロセス、およびネットワーク接続を非表示にします。バックドアを追加します。など。
- ユーザーjohnは、johnnという名前のpfe1で別のアカウントを作成、削除、および再作成しました。ユーザーjohnは、ユーザーjohnnのホームディレクトリを隠しファイルにして、このユーザーアカウントの存在を隠しました。
- ユーザーjohnがファイル
/bin/trueをコピーしました/bin/false以上 次に/bin/bash/bin/false以上 インタラクティブログインには通常使用されないシステムアカウントのログインを容易にするため。 - ユーザーjohnは、システムアカウントwhoopsieとlightdmのパスワードを作成しました。これらのアカウントには通常、パスワードがありません。
- ユーザーアカウントjohnnは正常にログインし、ユーザーjohnnはユーザーwhoopsieおよびlightdmになろうとしましたが失敗しました。
- サーバーpfe1が深刻に侵害されました。
PFEへの私の推奨事項
- 元のディストリビューションからサーバーpfe1を再構築し、関連するすべてのパッチをシステムに適用してから、サービスに戻します。
- 集中型syslogサーバーをセットアップし、PFEハイブリッドクラウド内のすべてのシステムを集中型syslogサーバーにログに記録します ローカルログに移動してログデータを統合し、システムログの改ざんを防ぎます。セキュリティ情報およびイベント監視（SIEM）製品を使用して、セキュリティイベントのレビューと関連付けを容易にします。
-
bashを実装します すべての会社のサーバーでコマンドのタイムスタンプ。 - すべてのPFEサーバーでrootアカウントの監査ログを有効にし、監査ログを一元化されたsyslogサーバーに転送して、他のログ情報と関連付けることができます。
- IPアドレス
192.168.56.1でシステムを調査します pfe1の侵害の要点として使用されたため、侵害と侵害の場合。
フォレンジックを使用してLinuxファイルシステムの侵害を分析したことがある場合は、コメントでヒントと推奨事項を共有してください。
Gary Smithは、今年LinuxFestNorthwestで講演します。プログラムのハイライトをご覧になるか、参加登録してください。