DNSトンネルを利用したデータ流出の検知について

Pocket

DNS をつかったデータ流出検知の方法が以下のサイトにいろいろ書いてありそうだったので少し調べてみた。

Monitoring a network for DNS exfiltration(Splunk)
https://lantern.splunk.com/Security/UCE/Guided_Insights/Threat_hunting/Monitoring_a_network_for_DNS_exfiltration

なお、DNSトンネルについては以下のサイトに詳しく書いてある。

DNSトンネリングの現状: OilRigのDNSトンネリング概要
https://unit42.paloaltonetworks.jp/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/

ドメイン名のしくみ(JPNIC)
https://www.nic.ad.jp/ja/dom/system.html

ネットワーク内のDNSトンネリングを検出する方法とは? (Cato)
https://www.catonetworks.com/ja/blog/how-to-detect-dns-tunneling-in-the-network/

[DNS入門] 基礎から分かる「DNSトンネリング」とは(Infoblox)
https://note.com/infoblox/n/n963e909a3ebc

遠隔操作ウイルスの制御にDNSプロトコルを使用する事案への注意喚起(ラック)
https://www.lac.co.jp/archive/20160201_000310.html

上記サイトではこのため、サブドメインは長さが63文字未満でなければならず、また、サブドメインを含むクエリ対象のドメイン全体が253文字を超えることはできない、と書いてある。

また、DNSトンネリングを検知するには以下の手法がよさそうである。

・長いDNSクエリを調べる。
・一般的でないDNSクエリタイプを調べる(TXT, CNAME, MX等)
・上記2つに該当したDNSクエリの送信先を検証し、過去に遡って他にも長いパケットがないか確認する。

1.Increases in DNS packet size and volume

DNSクエリが異常に長いドメインを検知するものと思われる。

Increases in DNS packet size and volume 
https://lantern.splunk.com/Security/UCE/Guided_Insights/Threat_hunting/Monitoring_a_network_for_DNS_exfiltration/Increases_in_DNS_packet_size_and_volume

これをChatGPTに説明してもたらった結果は以下の通り。

このSPLクエリは、DNSクエリの長さ(queryLength)を元に、ソースごとのクエリ数を集計し、最も長いクエリを送信しているソース(src)を特定するためのものです。クエリの各ステップを解説します。
SPLの解説:

eventtype="stream_dns" message_type="Query"
ここで、eventtype="stream_dns"は、DNS関連のイベントを指しています。message_type="Query"は、DNSクエリ(ドメイン名解決の要求)のみを対象にします。これにより、DNSクエリに関するログだけを取得しています。

mvexpand query
queryフィールドにマルチバリュー(複数の値を持つフィールド)が含まれている場合、それを個々の値に展開します。つまり、複数のDNSクエリが1つのイベントに含まれていた場合、それを個別に分割して処理します。

eval queryLength=len(query)
evalコマンドを使用して、queryフィールド(DNSクエリ文字列)の長さを計算し、queryLengthという新しいフィールドにその結果を格納しています。これにより、各クエリの文字数が計算されます。

stats count BY queryLength, src
statsコマンドで、queryLength(クエリの長さ)とsrc(クエリの送信元IPアドレス)ごとに集計を行い、クエリの長さごとのクエリ数(count)を計算します。これにより、各IPアドレスが送信したクエリの長さとその回数が分かります。

sort -queryLength, count
queryLength(クエリの長さ)とcount(クエリ数)を基準に降順でソートします。まず、クエリの長さが長い順にソートし、次にクエリの数が多い順に並べ替えられます。

table src queryLength count
src(送信元IPアドレス)、queryLength(クエリの長さ)、およびcount(クエリ数)を表示するため、これらのフィールドだけを抽出してテーブル形式で表示します。

head 1000
headコマンドを使用して、上位1000件のレコードを表示します。最も長いクエリを持つソース上位1000件がリストアップされます。

まとめ:

このクエリは、DNSクエリの長さに基づいて、送信元IPごとのクエリ数を調べ、特に長いクエリを送信しているソースを特定します。これにより、異常に長いDNSクエリを送信するソース(例えば、DNSトンネリングやコマンド&コントロール通信に関連するもの)を特定することができます。
MITRE ATT&CKテクニック

このクエリもDNSログを対象としているため、DNSを使用する攻撃者の活動を特定することが可能です。関連するMITRE ATT&CKテクニックは次の通りです。

T1071.004 - Application Layer Protocol: DNS
攻撃者がDNSプロトコルを使用してコマンド&コントロール通信を行う際、通常よりも長いDNSクエリを利用することがあります。特に、DNSトンネリングではデータを隠して送信するため、異常に長いクエリを検出することは有効です。

T1568.002 - Dynamic Resolution: Domain Generation Algorithms (DGA)
DGAによる攻撃では、ランダムな文字列を持つドメイン名が生成されることが多く、これによりクエリが通常よりも長くなることがあります。このクエリの長さを分析することにより、DGAの使用を検出する手がかりになります。

まとめ:

このクエリは、DNSクエリの長さを基に異常なクエリやソースIPアドレスを特定することを目的としており、特にDNSを用いたコマンド&コントロール通信やDGAによる攻撃を検出するのに役立ちます。

たとえば以下のような検知はどうだろう?

<検知ロジック案>
1. "req"のFQDNの文字数を確認し、サブドメインが30文字以上のものを検知 or "req"のFQDNの文字数を確認し、全文字数が100文字以上のものを検知
2. DNSクエリタイプが"A"以外を検知
3. 上記2つに合致した場合、同様の問合せをしているドメインがないか確認する

2.Signs of beaconing activity

同じドメインに定期的にアクセスしているDNSクエリを検知するものと思われる。

Signs of beaconing activity
https://lantern.splunk.com/Security/UCE/Guided_Insights/Threat_hunting/Monitoring_a_network_for_DNS_exfiltration/Signs_of_beaconing_activity

3.Requests to a large number of subdomains

同じドメインなのにサブドメインがやたらと多いものを検知するものと思われる。

Requests to a large number of subdomains 
https://lantern.splunk.com/Security/UCE/Guided_Insights/Threat_hunting/Monitoring_a_network_for_DNS_exfiltration/Requests_to_a_large_number_of_subdomains

4.Requests to a large number of subdomains

DNSクエリにおけるサブドメインのランダム性を見るものと思われる。

Requests to a large number of subdomains 
https://lantern.splunk.com/Security/UCE/Guided_Insights/Threat_hunting/Monitoring_a_network_for_DNS_exfiltration/Requests_to_a_large_number_of_subdomains

これをChatGPTに説明してもたらった結果は以下の通り。

このSPLクエリは、DNSログに含まれるクエリに基づいて、各ドメインに関連するホスト数を集計し、最も多くのホストに関連するドメインを特定するためのものです。各ステップを日本語で解説し、その後に該当するMITRE ATT&CKテクニックも説明します。
SPLの解説:

tag=dns message_type="Query"
ここではdnsタグが付いているデータをフィルタし、message_typeが「Query」になっているもの(DNSクエリ)のみを対象にしています。つまり、DNSログのうち、DNSクエリ(ドメイン名を解決する要求)だけを対象にしています。

eval list="mozilla"
evalコマンドを使って、新しいフィールドlistに「mozilla」という文字列を設定しています。これは後で使われるカスタム関数でのフィルタリングに関連する設定であり、Mozilla関連のホストをリストに含めるためのものと思われます。

ut_parse_extended(query, list)
ut_parse_extended()はカスタム関数で、queryフィールド(DNSクエリ)を解析し、サブドメインやドメイン名を抽出します。ここでは、list("mozilla")というリストを基に、特定のドメイン(Mozillaに関連するドメインなど)を解析の際にフィルタリングする目的で使用されます。

stats dc(ut_subdomain) AS HostsPerDomain BY ut_domain
statsコマンドで、ut_domain(ドメイン)ごとに集計を行います。
dc(ut_subdomain)は、サブドメインのユニークな数を数えています。このユニークなサブドメインの数をHostsPerDomainという名前で新しいフィールドに保存しています。
結果として、各ドメインに関連するホスト(サブドメイン)の数が集計されます。

sort -HostsPerDomain
最後に、HostsPerDomainフィールド(ホスト数)で降順にソートしています。これにより、最も多くのホスト(サブドメイン)を持つドメインが上位に表示されます。

MITRE ATT&CKテクニック

このクエリは、DNSクエリログから特定のドメインに関連するホスト数を集計し、多数のホストに関連する異常なドメインを検出するために役立ちます。これに関連するMITRE ATT&CKテクニックは以下の通りです。

T1071.004 - Application Layer Protocol: DNS
DNSを利用した攻撃者の通信(特にコマンド&コントロール通信)を検出するために関連します。このクエリは、DNSクエリの中で特定のドメインに関連する異常なホスト数を発見するのに有効です。

T1568.002 - Dynamic Resolution: Domain Generation Algorithms (DGA)
DGAは攻撃者が多くの異なるサブドメインを使用して、C2サーバーと通信する技術です。多くのホスト(サブドメイン)を持つドメインがあった場合、それがDGAによる異常な通信の兆候かもしれません。このクエリで特定される「多くのサブドメインを持つドメイン」は、DGAの兆候を検出する際に有用です。

まとめ

このSPLクエリは、DNSクエリに基づいて各ドメインに関連するホスト数を集計し、多数のホストを持つ異常なドメインを特定するために使用されます。このクエリは、MITRE ATT&CKのT1071.004(DNSを使ったC2通信)やT1568.002(DGA)に該当する可能性があります。

5.Monitoring a network for DNS exfiltration(Splunk)

その中でも以下について確認してみた。

DNS tunneling through randomized subdomains 
https://lantern.splunk.com/Security/UCE/Guided_Insights/Threat_hunting/Monitoring_a_network_for_DNS_exfiltration/DNS_tunneling_through_randomized_subdomains

これをChatGPTに説明してもたらった結果は以下の通り。

このSPLクエリは、DNS(Domain Name System)に関連するログを解析し、ドメイン名やサブドメインに異常がないかをチェックするためのものです。クエリの各部分を日本語で解説します。

sourcetype=bro_dns
bro_dnsはDNSに関するログを表すsourcetypeです。ここでは、Bro/ZeekのDNSログが対象になっています。この行でまず、DNSのログを取得しています。

ut_parse(query)
ここで使われているバックティック(``)で囲まれたut_parse(query)はカスタム関数で、DNSクエリ(query)を解析し、サブドメインやドメイン名を取り出します。特にqueryフィールドからサブドメインを抽出する役割があります。

ut_shannon(ut_subdomain)
ut_shannon()はシャノンエントロピーを計算する関数で、ut_subdomainフィールドに対して計算されます。シャノンエントロピーはデータのランダムさ(複雑さ)を測る指標で、高い値はランダムであること、つまり異常やマルウェアの通信などを示唆する場合があります。

eval sublen=length(ut_subdomain)
evalコマンドを使って、ut_subdomain(抽出されたサブドメイン)の長さをlength()関数で計算し、その結果をsublenという新しいフィールドに格納しています。

stats count avg(ut_shannon) AS avg_sha avg(sublen) AS avg_sublen stdev(sublen) AS stdev_sublen BY ut_domain
statsコマンドで、各ドメイン(ut_domain)ごとに以下を計算します:
count: 該当するサブドメインの数
avg(ut_shannon): シャノンエントロピーの平均(avg_shaとして保存)
avg(sublen): サブドメインの長さの平均(avg_sublenとして保存)
stdev(sublen): サブドメインの長さの標準偏差(stdev_sublenとして保存)

search avg_sha>3 avg_sublen>20 stdev_sublen<2
このsearchコマンドで、シャノンエントロピーの平均が3より大きく、サブドメインの平均長が20より大きく、かつ標準偏差が2未満のものをフィルタリングしています。これは、非常にランダムで長いサブドメインを持つが、長さが一貫しているもの(すなわち、特定のパターンに従って生成された可能性が高いもの)を抽出します。

eval subdomain_samples = mvindex(domain_samples, 1,5)
mvindex()関数を使って、domain_samplesフィールドの最初から5番目までのサブドメインをsubdomain_samplesという新しいフィールドに格納しています。これは、サンプルとして5つのサブドメインを取り出して表示するためです。

sort - count
最後に、count(サブドメインの数)を基準に降順でソートしています。これにより、サブドメインの数が多いものが上位に表示されます。

まとめ:

このクエリは、DNSログからドメインごとにサブドメインのシャノンエントロピーや長さを分析し、異常なパターンを持つドメインを検出するために使用されます。

このSPLクエリは、DNSログの解析に基づいて異常なドメインやサブドメインを検出するためのものです。DNSトラフィックの異常なパターンを分析することは、攻撃者がコマンド&コントロール(C2)通信にDNSを利用するケースなどに対応します。

MITRE ATT&CKフレームワークの観点から見ると、以下のテクニックが関連している可能性があります。
1. T1071.004 - Application Layer Protocol: DNS

攻撃者がDNSプロトコルを使用してコマンド&コントロール(C2)通信を行う場合に該当します。攻撃者はDNSリクエストにデータを埋め込み、DNSトンネリングを利用して通信を隠すことがあります。このクエリは異常なDNSトラフィック(例えば、長いサブドメインやシャノンエントロピーが高いサブドメイン)を検出するため、DNSを使用したC2通信の検出に役立ちます。

2. T1568.002 - Dynamic Resolution: Domain Generation Algorithms (DGA)

DGAは、攻撃者が大量のランダムなドメイン名を生成し、C2サーバーと通信する際に使う手法です。このクエリは、サブドメインのシャノンエントロピーや長さを分析するため、ランダムなドメイン名を生成するDGAによる異常な通信を検出するのに有効です。

このクエリは、DNSを悪用する攻撃を検出するため、これらのMITRE ATT&CKテクニックに対応する可能性が高いです。

Comments

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA