Boss of the SOC (BOTS) Advanced APT Hunting Companion App for Splunk
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.

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

全１３回

DNS Exfiltration

DNS Exfiltration - Hypothesis

仮説
一般的なネットワークプロトコル、特にDNSを使用してデータの流出が発生する可能性があります
説明
データの抽出は、メインのコマンドおよび制御プロトコルまたはチャネルとは異なるプロトコルで実行されます。データは、メインのコマンドアンドコントロールサーバーから別のネットワークロケーションに送信される可能性があります。代替プロトコルには、FTP、SMTP、HTTP / S、DNS、またはその他のネットワークプロトコルが含まれます。さまざまなチャネルに、クラウドストレージなどのインターネットWebサービスを含めることができます。

How Might We Confirm or Refute Our Hypothesis?

どのデータソース（ソースタイプ）がDNSを参照または少なくとも参照していますか？
DNSのデータフローはどのように見えますか？
DNSクエリが発行されていることを確認できますか？
DNSを介した流出はどのようなものでしょうか？
DNSイベントはいつ発生しますか？
参照されるドメイン（およびサブドメイン）
参照されているドメインの詳細はどこで確認できますか？
インジケーター160.153.91.7は、仮説の確認に役立ちますか？

DNS Exfiltration - Searching with Indicator

DNSデータは何を教えてくれますか？

IPアドレスが160.153.91.7の場合、このインジケータを活用して、DNSを使用して流出が試みられたかどうかを判断できます。

DNS src and name Results

stream：dnsを使用しているため、Frothly内で発生するすべてのDNSクエリと応答のソースが用意されています。 DNSデータには他にも多くのソースがありますが、ストリームを使用すると、このデータを簡単に取得できます。 DNSデータでインジケーターを検索すると、4つの疑わしいシステムがすべて、イベントでこのアドレスへの参照を持っていることがわかります。 DNSレコードの名前フィールドも興味深いものです。名前レコードを見ると、hildegardsfarm.comがあります。

SPL

index=botsv2 sourcetype=stream:* 160.153.91.7 sourcetype=stream:dns
| stats count by name{} | eventstats sum(count) as perc | eval percentage=round(count*100/perc,2) | fields - perc |sort - count

nameだったので結果がでていなかった。Splunk Stream入っているのだけど。

Lots of DNS

一見すると、8月23日に少数のDNSイベントがありますが、数日後にははるかに多くのイベントがあります。 DNSパケットには多くのデータが保持されておらず、データの流出を探しているため、8月23日のこれらのいくつかのイベントは確認する必要があるかもしれませんが、現時点では、70K以上のイベントに注目しています。ピボットして、イベントのsrcとdestを確認できます。それらの大部分はサーバーのmercuryから発生しているようで、大多数はGoogleのDNSサーバーである8.8.8.8に送られます。

src_dns

index=botsv2 sourcetype=stream:dns hildegardsfarm.com 
| top src
| eval percent=round(percent,2)

src	count	percent
10.0.1.100	66842	90.55
10.0.1.101	6949	9.41
10.0.2.107	16	0.02
10.0.2.109	8	0.01
8.8.8.8	4	0.01

Network Resolution (DNS)@CIMを確認してもsrc_dnsは載ってなかった。

message_typeを見ると、クエリと応答の両方があることがわかります。この時点で、外部ホストを探したい場合、それはクエリになります。なぜなら、内部ホストは、DNSクエリに埋め込まれた情報を送信し、敵に送信できるからです。それを念頭に置いて、クエリ値をドリルダウンしてみましょう。

DNS Exfiltration - URL Toolbox

統計とURL Toolboxを使用してDNS流出を特定する

URL Toolboxアプリは、ドメインを解析して、ドメインとサブドメイン、およびその他の要素を含む断片に機能を提供します。この解析が完了すると、statsコマンドを使用してデータ内の外れ値を特定できます。それらを協調して使用すると、DNS流出の指標を探すのに役立ちます。

Interesting Query Values

message_typeをqueryに設定すると、tableコマンドを使用して、_time、query、src、destのフィールドのサブセットを出力できます。クエリフィールドには、ドメインhildegardsfarm.comのクエリの一部である奇妙なサブドメインがあります。 evalおよびstatsコマンドを使用して、これらの結果の追加分析を実行できます。

Enter Our Friend, URL Toolbox

hildegardsfarm.comのサブドメインを含むクエリのみをトラフィックに制限することにより、以前の検索を拡張しましょう。出力を少しクリーンアップするには、evalステートメントを使用して、クエリフィールドの値を重複排除します。

それが完了したら、URL Toolboxというアプリを使用します。この小さな宝石により、ドメインとURLを取得し、それらをトップレベルドメイン、ポート、サブドメインなどの個別のフィールドに分解できます。また、特にシャノンエントロピーを計算する方法を提供します。

mozillaリスト（URL Toolboxの一部）を参照し、クエリフィールドに対してut_parse_extendedマクロを実行する必要があります。これにより、クエリが細かく分割されて分析されます。次に、抽出されたサブドメインのシャノンエントロピースコアを計算し、出力を表にできます。

結果を確認すると、これらのサブドメインはすべて高いエントロピースコアを持っていることがわかります。 3を超えるエントロピースコアは高いと見なされ、ドメインまたはURLがアルゴリズムによって生成されるかどうかを判断するためにしばしば使用できます。エントロピーは完全ではなく、AWSサブドメイン名を見るだけですが、DGAを示すのに役立つツールチェスト内の別のツールであり、追加の問い合わせが必要です。

DGA Domain Generation Algorithm

Take a Step Back and Assess

これらのサブドメインと関連するクエリをより大きなデータセットとしてさらに分析することで、以前の検索をさらに進化させることができます。シャノンエントロピースコアを計算した後にevalステートメントを使用すると、各サブドメインの長さを計算できます。 statsコマンドを使用して、平均シャノンエントロピースコア、サブドメインの平均長、およびドメインによるサブドメインの長さの標準偏差を決定できます。

一般に、平均エントロピーが高く、サブドメインの長さが長く、長さの標準偏差が低いことと、イベントカウントが多いことは、DNS流出の試みを示している可能性があります。なぜあなたは言うのですか？

DNS Exfiltration - How It Works

DNS流出はどのように機能しますか？

DNS Exfiltrationは、ファイアウォールやルーターを介してデータを送信する場合と少し異なります。 DNSの制限を理解することは、DNSを使用した流出試行の識別に役立つDNSの異常を探すための方法を提供します。

DNS Exfiltration Visualized - Part 1

ファイアウォールを介してファイルtopsecretyeast.pdfを抽出したい場合、ファイアウォールはパケット検査を介してファイル内の好ましくないものを識別し、ファイルの送信を阻止する可能性があります。

ただし、DNSに関しては、DNSがインターネットに出て、アドレスの検索ができるようにする必要があります。したがって、DNSアウトバウンドははるかに寛容です。抽出するファイル内のデータをエンコードできれば、大きなDNSサブドメインクエリリクエストとしてデータを簡単に送信できますか？

そんなに早くない。 DNSパケットには制限があります。

DNS Exfiltration Visualized - Part 2

DNSパケットが大きすぎる場合、要求はDNSクエリではないことが明らかなので、ファイアウォールはそれらを拒否できます。ただし、ファイルを取得して複数のDNSクエリに分割できる場合は、できるだけ多くのDNS要求を介して送信できます。これは、正当なDNSトラフィックのように見えるため、ファイアウォールの回避に役立ちます。ただし、これらのクエリにはすべて料金がかかります。

Pulling it Together

以前の検索をもう少し変更した場合、srcコマンドとdestアドレスをstatsコマンドに追加して、カウントを追加できます。これで、hildegardsfarm.comのドメインを持つ各srcとdestのペアの個別の統計ができました。 DNSクエリの数が非常に多く、すべてがかなりランダム化（エントロピー）されており、サブドメインの長さが同じで標準偏差がないことに注意してください。クエリに16文字が繰り返し詰め込まれているのを見ると、DNSを介して大規模なファイルを盗もうとしている可能性があります。

狩りに関しては、FTPの流出に加えてDNSの流出が発生していると確信を持って言えます。

Whois - Hildegardsfarm.com

この時点で、ドメインhildegardsfarm.comは、使用されているftpアカウント名と、DNS流出スキームと思われるもので参照されているドメインとの間で問題があるという高いレベルの自信を持っています。 DomainToolsのWhoisレコードを見ると、ドメインの作成日時、レジストラの作成者など、ドメインのIPアドレスがわかります。ここでの問題は、ここにリストされている使い慣れたIPアドレスが表示されないことです。おそらく、攻撃が発生してからIPアドレスが変更された可能性があります。他にどんなオプションがあるのか見てみましょう...

whois@domaintools.com

OSINT - hildegardsfarm.com

RiskIQのCommunity Editionなどのツールを使用する場合、ドメインを検索して解決の履歴を振り返ると、7月23日から9月14日までにドメインが解決されたIPアドレスは160.153.91.7であることがわかります。 IPアドレスはおなじみのように見え、実際には、ビリーとケビンのワークステーションが通信していたのと同じIPアドレスです！

hildegardsfarm.com@securitytrails.comでも出てた。
結果はRiskIQと一緒
160.153.91.7 GoDaddy.com, LLC 2017-07-23 (2 years ago) 2017-09-15 (2 years ago) 1 month
VirusTotalは出なく、OTXAlienVaultは時期がずれていた。

DNS Exfiltration - Findings

Were We Able To Confirm Our Hypothesis?

DNSが流出に使用されているのを見ました
- おそらくファイアウォールをバイパスしようとする試み
- それが完全に成功したかどうかは不明ですが、試みられ、イベントが去っていくのが見られました

What We Learned

外部IP 160.153.91.7を参照する4つのシステムが見られました
DNSはhildegardsfarm.comというドメインを参照しました
このドメインへのDNSクエリは、サブドメインのエントロピーが高く、イベントカウントが多く、DNSトンネリングを示す可能性のある標準偏差が低い
OSINTは、hildegardsfarm.comの現在のIPアドレスは（当社にとって）既知のIPではありませんが、攻撃時にドメインに解決されたIPは160.153.91.7であることを示します

What should we operationalize?

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

ブラックリスト
- IP-160.153.91.7（基本、簡単に歩き回りますが、考慮すべきこと）
- ドメイン-hildegardsfarm.com
DNSトラフィックの標準偏差が低い、高エントロピー、サブドメイン長の長い文字列を監視します
システムのトラフィック分析を実行して、外部システムと内部システム間の通信のベースラインを確立します

まとめ

DNSトラフィックを利用しての情報流出は通信先としてはログに出てこないのがわかりづらい。
base64に結合できるかといろいろ試したけど、ダメだった。残念

参考情報@PaloAltoがわかりやすかったし、ようやく理解できた。

Splunk BOSS of the SOC ver 2について(DNS Exfiltration)