Splunk BOSS of the SOC ver 2について(その２ Account Persistence)

[Boss of the SOC (BOTS) Advanced APT Hunting Companion App for Splunk](https://splunkbase.splunk.com/app/4430/)
Hunting an APT with Splunk Workshop
Welcome to the Hunting an APT with Splunk Workshop based on the Boss of the SOC 2017 data set.

こちらを元に、手順を追ってみる。データセットは[ここ](https://github.com/splunk/botsv2)
なお、ログの時間を合わせるためユーザの時間帯を**(GMT -08:00)**にする必要がある。

全１３回

1. [概要とPowerShell Empire](https://qiita.com/toshikawa/items/511af1a3054ab81cd475)
2. [FTP Exfiltration](https://qiita.com/toshikawa/items/ca6483e4c0ef7f3bb9d3)
3. [DNS Exfiltration](https://qiita.com/toshikawa/items/93a57d9ac0e06bab0bde)
4. [Adversary Infrastructure](https://qiita.com/toshikawa/items/75cbfa0b522735bc5228)
5. [Spearphishing Attachment](https://qiita.com/toshikawa/items/b9bc3527c0f9787d6be1)
6. [User Execution](https://qiita.com/toshikawa/items/945e271b05c1ea55ef34/)
7. [Account Persistence](https://qiita.com/toshikawa/items/df27a896ab71bafb512d)
8. [Scheduled Task](https://qiita.com/toshikawa/items/b203eb78c699192cfc6d/)
9. [Indicator Removal](https://qiita.com/toshikawa/items/8e0c730280e051a3ed4e/)
10. [User Agent Strings](https://qiita.com/toshikawa/items/bb0055bf74af461824a9/)
11. [OSINT Gathering](https://qiita.com/toshikawa/items/4cad2830289bc83ca330/edit)
12. [Lateral Movement](https://qiita.com/toshikawa/items/054c8c358c79758dec25/)
13. [Data Staging](https://qiita.com/toshikawa/items/886df42faf744c299985/)

#Account Persistence
##Create Account - Hypothesis
>仮説
攻撃者は、ユーザーアカウントを作成して、企業全体で永続性を維持しようとします。
説明
十分なレベルのアクセス権を持つ敵は、ローカルシステムまたはドメインアカウントを作成する可能性があります。 このようなアカウントは、永続的なリモートアクセスツールをシステムに展開する必要のない永続化に使用できます。

####How Might We Confirm or Refute Our Hypothesis?
- ユーザーアカウントの作成を識別するために必要なデータソース（sourcetypes）は何ですか？
- ユーザーアカウントの作成を示す特定のイベントコードまたは値はありますか？
- 複数のユーザーアカウントが作成されている場合に探す共通点はありますか？ 違いはどうですか？
- ユーザーアカウントはいつ作成されますか？
- これらのアカウントを作成したのは誰ですか？
- どのグループに追加されましたか？
- どのシステムがアカウント作成を開始しましたか？

##Create Account - Where To Start
>どんな種類のデータがありますか？

>敵がネットワークに侵入すると、攻撃の重要な部分は永続性を確立することです。 これは、攻撃者が自分の存在に注意を喚起し、攻撃者が元の攻撃と同じ手法を使用してアクセスできないように変更を加えるリスクを軽減するためであり、他の手段を介してシステムにアクセスできます。 永続性を維持する良い方法は、将来接続できるアカウントをセットアップすることです。

####Where to Start?
>Windowsシステムのある環境で狩りをしている場合、開始するのに適した場所は、アカウント作成のイベントコードを検索することです。 返される最初の結果は、WindowsイベントID 4720、「ユーザーアカウントが作成されました」イベントです。

####Windows Event Logs & 4720
>そのイベントコード4720で検索を開始し、Windowsイベントログを検索すると、8月中に4つのアカウント変更が発生したことがわかります。

####What’s in this log?
- 件名
- 新しいアカウント
- 属性
- 追加情報

>イベントの確認を始める前に、Windowsイベントの内容を簡単に見てみましょう。 高レベルでは、イベントは4つのセクションに分かれています。 件名、新しいアカウント、属性、追加情報。 件名セクションは、アカウント名が存在する場所であり、新しいアカウントを要求する個人になります。 [新しいアカウント]セクションにはアカウント名もありますが、これは少し混乱する可能性があります。これは新しく作成されたアカウント名です。 SAMアカウント名は[属性]セクションに保存されますが、通常は[新しいアカウント]セクションのアカウント名と同じ値になります。

>Windowsイベントログの例を次に示します。 上部に一般的なWindowsイベント情報が表示されます。 [件名]セクションには、FROTHLYドメインのsvcvncという新しいユーザーの作成を要求する、ドメインFROTHLYのservice3のアカウント名が表示されます。 右側には、表示名、ホームドライブとホームディレクトリ、アカウントの有効期限、パスワードの最終セットなどの属性が多数あることがわかります。

####Drilling into Key Account Name Fields
>その背景で、検索に戻り、SAM_Account_NameフィールドとAccount_Nameフィールドにピボットしましょう。 これらのユーザーアカウント作成イベントでsvcvncが4回参照されていることがわかります。 他のアカウント名の値はservice3とbilly.tunです。

##Create Account - Attributes
>Windowsイベント内の属性

>Windowsイベント内で、このアクティビティが組織のアカウント作成用に確立された標準に準拠している場合、属性を使用して手がかりを探すことができます。 そうでない場合は、さらに調べる必要があります。

####Where and When Were Accounts Created?
>出力用のテーブルコマンドを追加して検索を変更すると、これらのイベントのタイミングと発生したシステムを確認できます。 2つのワークステーションと2つのサーバーで発生したイベント作成ログを確認できます。 どうやってそれを知るのですか？ 以前のハントで思い出したように、資産は定義されており、すぐに資産センターに戻ってこの情報を確認できます。 Billyのワークステーションがユーザーを追加した最初のワークステーションであり、アカウントservice3が他のシステムに使用されたようです。

####Comparing Account Attributes
>このような短期間で4つの異なるシステムで作成された同じアカウントの作成は疑わしいです。 これをさらに分析するために、Windowsイベントログの属性値を取得し、tableコマンドとtransposeコマンドを使用して、すべてのシステムの値を比較できます。 これらの追加フィールドは、すべてのシステムで一貫して空であることがわかります。 これらの属性のいずれも設定されていないことは非常に奇妙に思えます。

####What Else Should We Look For?
>4720アカウントの作成を補完する他のWindowsイベントコードを探すこともできます。 そのためには、最初のアカウントが作成された直後から最後のアカウントが作成された直後まで、時間枠を調整する必要があります。 それに基づいて、8月23日の時間ウィンドウを20:42から21:20に設定します。ここでは、アカウントが作成されたのと同じ頃に発生した4720に加えて、コード付きのイベントを多数見ることができます。

>いくつかの良い例には、ユーザーがそれぞれグローバルセキュリティグループとローカルセキュリティグループに追加されたことを示すイベントコード4728と4732が含まれます。 これらのイベントは、アカウントが作成されたのとほぼ同時に発生しました。

####Explicit Credentials Events
>Windowsイベントコード4648を探すこともできます。明示的な資格情報を使用してログオンが試行されました。 これは、ログインしているが別の資格情報でプロセスを実行しているユーザーを探すときに役立ちます。 これはすべてBillyのワークステーションで行われているため、service3アカウントはwrk-klagerf、venus、mercuryなど、ネットワーク上の他のシステムへのログインに使用されています。

##Create Account - Findings
####Were We Able To Confirm Our Hypothesis?
- 永続性を維持するために、複数のシステムでアカウントが作成されています

####What We Learned
- ユーザーアカウントsvcvncは4つのシステムで作成されました
 - 2台のサーバー（mercuryとvenus）
 - 2ワークステーション（wrk-btunおよびwrk-klagerf）
- すべてのアカウントは、8月23日の40分以内に作成されました
- 最小限の情報がユーザー作成に挿入されました
- service3アカウントによって3つのアカウントが作成されました
- 最初のアカウントは、billy.tunアカウントによって作成されました
- billy.tunアカウントにユーザーを作成する権限エスカレーションがあったイベントは確認していません
 - ログがありませんか？
 - これはメモリベースのエクスプロイト（mimikatz？）だったので、表示するイベントはありませんでしたか？

####What should we operationalize?
>各ハントの終わりに、私たちは何を取り、インシデント対応チームにフィードバックできるかについて考えたいと思います。 これは、ボックスを引っ張ってフォレンジックアクティビティを実行するなどの追加アクティビティであるか、インジケータを取得してSIEMまたはログ管理システムにフィードするか、発見したことに基づいて新しい分析とアラートを構築することができます。 一日の終わりには、先ほど言ったように、狩りから何かを学ぶ必要があります！

- これらのユーザーアカウントの作成は、標準または予想される時間枠で行われていますか？
- アカウント属性が設定されていますか？
 - それらの少なくともいくつか？
 - それらは、組織が使用する標準フィールドのパターンに従っていますか。つまり、ユーザープリンシパル名とホームディレクトリおよびアカウントの有効期限は常に入力されていますか。
- 別のパターンは赤い旗である可能性があります
- 同じアカウント名が複数のシステムで作成されていますか？
 - アカウントを作成しているユーザーは誰ですか？
 - 名前付きユーザーアカウントvサービスアカウント
- 通常、アクションを実行するユーザーには適切な権限がありますか？
- アカウント作成ポリシーに応じて、ここに行く方法がたくさんあります
- Windows 4648イベントも役立ちます

##まとめ
windowsのEventLog関連は
[Security Essential@local Splunk](http://localhost:8000/ja-JP/app/Splunk_Security_Essentials/data_source?datasource=Windows%20Security#Enabling_Windows_Security_Log)とかを参考にしたい。