はじめに

表題のとおり、本記事はLetsDefendでの疑似アラート対応に関するWriteup記事です。
当アラートの対応を行わない方には、本記事は有用でないかもしれません。

また、本記事の考え方や対応に問題があれば、コメントでご指摘くださればと思います。
　

[補足]
Lets Defendは、ブルーチームのトレーニングを積めるウェブサイトです。
ご興味がある方はぜひ覗いてみてください。

ウェブサイトは日本語に対応してませんが、最近だと翻訳機能が優秀なので学習で困ることはないと思います。

Writeup

ステップ１　アラートの把握

[Monitoring > INVESTIGATION CHANNEL] でアラートの概要を把握

以下の項目に着目することで、本アラートの大要は掴めるかと思います。

Rule
ファイルとディレクトリの探索が検出されました
　
Trigger Reason
機密ファイルとディレクトリへの不正アクセス
　
L1 Note
アラートの数分前に、IP 169.150.218.77 の異なるユーザーによるシステムへのブルートフォース攻撃が行われているのが目撃されました。しかし、この攻撃が成功したかどうかは判断できませんでした。
　
Command Line（詳細な解説は、本文下端の「補足」にて）
ls -R | grep ":$" | sed -e 's/:$//' -e 's/[^-][^\/]*/--/g' -e 's/^/ /' -e 's/-/|/'

【当時点での自分の調査方針】

以下2点の真偽の調査
- ブルートフォースによる認証情報の入手
- 不正ログイン後のファイルとディレクトリの探索
  　
真である場合、不正ログイン後のアクティビティ調査を行い、スコープや対応内容を明確にしていく

ステップ2 プレイブックに基づいた対応

Case Management でプレイブックに沿った対応を進める

Log Managementにおいて調査を進める

Basic検索において 169.150.218.77 でフィルタリングを行ったところ、検知時間 ”May, 08, 2024, 06:36 AM” の直前に、外部IPアドレス 169.150.218.77 からPort 22 に対する多数の通信ログが存在。ブルートフォース攻撃が疑われる。
　

Raw log を確認すると、上画像のようにssh接続にてパスワードを間違っていることにより認証失敗しているログが多数確認された。
　
次に認証に成功しているSSH通信がないかを確認するため、以下の条件でログをフィルタリングを行った。
【不審と思われるIPとURI】
- 46.30.215.78
- 104.244.42.65
- http://space-nickel.fr/
上記5つのアクティビティを最後として、当エンドポイントのアクティビティログは見受けられない。そのため、ラテラルムーブメントが行なわれたことによる調査スコープの拡大は、考えなくてもよいと判断。

プレイブックに戻って対応
　
OSを聞かれる。下画像のように、OSは Endpoint Security で確認できる。

　
どのような調査行為が行われたのかを選択する。

コマンドラインからディレクトリの列挙が確認されているため、"File and Directory Discovery"を選択
　
　
外部IPアドレスからのSSH接続があったことから"External"を選択

　
　
調査で発見した、不審と思われるIPとURIをレピュテーションサイトで調査する。　

　
例として、Virus Totalにて　"http://space-nickel[.]fr/" の判定を行ったところ、悪性の判定がなされた。

他の調査の結果として "104.244.42.65" は X(旧Twitter)所有のIPアドレスであることが判明した。
　
スコープに関しては、攻撃者によるものと思われるアクティビティは、1台のエンドポイントに対してのみであり、かつラテラルムーブメントによる活動範囲の拡大といった動きも見られなかったため、"No"を選択

　
攻撃が疑われるため、エンドポイント隔離をすべきと判断。 "Yes"を選択

　
Endpoint Security の画面で端末隔離を実行

　
今後の対策

日本語訳：
　サイバー攻撃はどのように発生したのか？スタッフと管理職はインシデントにどの程度適切に対応したか？次回同様のインシデントが発生した場合、スタッフと管理職はどのような異なる対応が可能か？
　将来同様のインシデントを防止するために、どのような是正措置が有効か？将来同様のインシデントを検知するために、どのような前兆や指標を監視すべきか？
　
　
IoCを入力し、プレイブックを使った対応完了

ステップ3 アラートのクローズ

[Monitoring > INVESTGATION CHANNEL] の画面で対象アラートに対し、"Alert Close"を押下

別のアラートでスクリーンショットを取得しているため、イベントIDが"255"ではなく"200"となっています。
　
以下を入力して、"Close Alert"を押下　
- True Positive
- Note:
  SSH（ポート22）に対するブルートフォース攻撃により認証情報が取得されました。その認証情報を用いてログイン後、端末内のディレクトリ構造の列挙やその他の情報収集が行われました。その後、X（旧 Twitter）および http://space-nickel[.]fr/ との通信の痕跡が確認されました。本連続的な行為は悪性と判断され、当該端末を隔離しました。
  　
  　
  その後、[Monitoring > Closed Alerts] の画面で結果が表示されます
  
  　
  これにてアラート対応は完了！

補足

検知コマンドラインの解説（生成AIより）

ls -R | grep ":$" | sed -e 's/:$//' -e 's/[^-][^\/]*\/--/g' -e 's/^/ /' -e 's/-/|/'

ls -R
- ls -R は、カレントディレクトリとそのサブディレクトリを再帰的にリスト表示します。
- サブディレクトリを列挙する際、その名前の後にコロン (:) がつきます。これが後続の処理に役立ちます。
  　
grep ":$"
- grep ":$" は、ls -R の出力から、末尾にコロン (:) がついている行だけを抽出します。
- これにより、ディレクトリ名のみが抽出され、ファイルのリストは除外されます。
  　
sed -e 's/:$//'
- sed コマンドは、文字列を置換します。s/:$// は、行末のコロンを取り除きます。
- これにより、ディレクトリ名の後についていたコロンが削除され、純粋なディレクトリ名が残ります。
  　
sed -e 's/[^-][^\/]*\/--/g'
- この正規表現は少し複雑ですが、基本的にディレクトリツリーの構造を扱います。
- [^-][^\/]*\/-- は「/ で区切られたサブディレクトリのパターン」で、- を除去します。
  - これにより、サブディレクトリの一部や不要な部分が除去されるため、ツリー状の表示がクリーンになります。
sed -e 's/^/ /'
- s/^/ / は行の先頭にスペースを追加します。
- これにより、ディレクトリツリーの各レベルが視覚的にインデントされます。深い階層ほどスペースが多くなり、ツリーの形を成すようになります。
  　
sed -e 's/-/|/'
- s/-/|/ は、を | に置換します。
- これにより、ツリー構造の見た目が「|」を使った線のように表示され、階層構造がより視覚的にわかりやすくなります。

結果として得られるもの：

このコマンドラインの最終的な出力は、ディレクトリ構造をツリー状に表示します。各ディレクトリレベルにインデントが付き、| 記号で階層を表現することで、フォルダの階層が視覚的にわかりやすくなります。

例えば、次のような結果になります（実際のディレクトリ構造によって異なる）：
```
|── dir1
|   |── subdir1
|   |── subdir2
|── dir2
|   |── subdirA
|   |── subdirB
```
これを実行することで、ターミナル上で簡単にディレクトリツリーを確認することができます。