以下、さわってみた感じ。








mitre_techniques.csv を開き、最後の行で右クリックしてコンテキストメニューを表示したところ

編集した直後

inputlookupコマンドで行を追加した結果を確認したところ

WHY DON'T YOU DO YOUR BEST!!
以下、さわってみた感じ。








mitre_techniques.csv を開き、最後の行で右クリックしてコンテキストメニューを表示したところ

編集した直後

inputlookupコマンドで行を追加した結果を確認したところ

新規にSplunkで監視ルールを作成する際の情報が流れとしてまとまったサイトがなかったのでまとめてみました。
例えば、AADRiskyUsersのログであれば、Identity Protectionの機能から出力されるよね、といったことを整理していく。
リスク データをエクスポートする(Microsoft Learn)
https://learn.microsoft.com/ja-jp/entra/id-protection/howto-export-risk-data
ログを出力する機能が分かれば、MITRE CTID やDTT&CTなどを使って、ATT&CKのどのテクニックが検知できるか確認する。
Microsoft Azure Security Control Mappings to MITRE ATT&CK®(MITRE CTID)
https://center-for-threat-informed-defense.github.io/security-stack-mappings/Azure/README.html
rabobank-cdc / DeTTECT
https://github.com/rabobank-cdc/DeTTECT
検知できそうなテクニックがわかったら、それに該当する検知ルールを Splunk Security Content や Sigmaルールを活用し検討する。
Splunk Security Content
https://research.splunk.com/detections/
SigmaHQ / sigma
https://github.com/SigmaHQ/sigma/tree/master/rules/cloud
NVISOsecurity / sigma-public
https://github.com/NVISOsecurity/sigma-public
SIGMAルールとは、Splunk など製品固有の言語(SPLなど)で書かれた検知ルールではなく、より汎用的?に記載された検知ルールのようです。
したがって、SIGMAルールがあれば、そこから Splunk や Sentinelなどいろいろなベンダーの SIEM で利用できる検知ルールが作成できます。
ちなみに SIGMAルールは以下のGITHUBのサイトなどに置かれています。
GITHUB
https://github.com/SigmaHQ/sigma/tree/master
https://github.com/NVISOsecurity/sigma-public
なお、SIGMAルールから各SIEM固有の検知ルールを生成する方法としては、 Webサイトのサービスを利用する方法とコマンドラインの2通りがありそうです。
Webサイトとしては、以下のUNCODER.IOが有名のようです。
UNCODER.IO
https://uncoder.io/
以下が実際の画面ですが、変換先を見ると Splunk, Sentinel, QRader, XSIAMと有名どころのSIEMへの変換が可能なようです。

そして実際に Splunkの SPLに変換してみたのがこちらです。変換後はシンプル&見慣れた表現なので少しわかりやすいですね。

コマンドとしては sigmatools というものがあるようで、以下のコマンドで簡単にインストールできます。
% pip3 install sigmatools
そして、UNCODER.IOで変換したものと同じSIGMAルールを sigmac コマンドでも変換してみた結果がこちらです。
% vi tmp/proxy_susp_flash_download_loc.yml
% sigmac -t splunk -c splunk-windows tmp/proxy_susp_flash_download_loc.yml
(((c-uri="*/flash_install.php*" OR c-uri="*/install_flash_player.exe") NOT ((cs-host="*.adobe.com"))))
-t の引数で変換先の SIEM として Splunk を指定しています。
Webで変換したものと大体一緒ですが、なぜか先頭に “source=”が付いていませんね。引数が足りないのかな?
<参考サイト>
・Sigmaルールのすすめ(Qiita)(https://qiita.com/sec-chick/items/4416bff231d7a55da75a)
・SIEMクエリ変換ツール「Sigma」を使ってみた(DeveloppersIO)(https://dev.classmethod.jp/articles/sigma-siem-transition-tool/)
・SIEMシステム用シグネチャフォーマット「Sigma」とSigmaルールの変換ツール「Uncoder.io」のご紹介(NEC)(https://jpn.nec.com/cybersecurity/blog/221014/index.html)
タイトルのとおり、SplunkのAddonとして提供されているAbuseIPDB Check をSplunkにインストールして軽く使ってみましたので、その時の操作をここに記録しておきます。
以下のサイトからAbuseIPDB Check の Addonをダウンロードできますので、Splunkサイトにログインの上、ダウンロードします。
https://splunkbase.splunk.com/app/4903
Splunkダッシュボードの左上にある「Appの管理」(歯車マーク)をクリックし、Appの管理画面の右上にある「ファイルからAppをインストール」から、1.でダウンロードした tgzファイルをインストールします。
Macの場合、/Applications/Splunk/etc/apps/abuseipdb_check フォルダにAppの本体がインストールされます。
さらにその配下の defaultフォルダにconfig.json ファイルが置かれていますので、 defaultフォルダと同じ階層にある localフォルダにコピーします。
cd /Applications/Splunk/etc/apps/abuseipdb_check/default/ cp config.json ../local
そして、localフォルダにコピーしたconfig.jsonファイルを編集します。
config.jsonファイルを vi などで開くと以下の通り書かれていますので、「yourkeyhere」の部分の AbuseIPDBサイトの自分のアカウントからとってきた API Keyに置き換えます。
{
"abuseip": [
{
"api_key": "yourkeyhere"
}
]
}
3.まで実施したら以下のコマンドでSplunkを再起動します。
/Applications/Splunk/bin/splunk restart
Splunk が再起動したら、再度「Appの管理」を確認すると、以下の通りAbuseIPDB Checkが登録されているはずです。

これで AbuseIPDB Check Appの abuseip コマンドが利用できるようになっているはずですので、以前対応した Virus Totalの vt4splunk と同じ要領で指定したIPの評価をAbuseIPDBからとってきます。
| makeresults | eval testip="8.8.8.8" | abuseip ipfield=testip

なお、Virus Totalと同時に評価をとってくることも可能なようです。
| makeresults | eval testip="8.8.8.8" | abuseip ipfield=testip | vt4splunk ip=testip

ちょっとテーブルの体裁を整えてみたのがこちら。
sourcetype=stream:http | vt4splunk ip=dest_ip | abuseip ipfield=dest_ip | table _time,dest_ip, AbuseConfidence, vt_detections,vt_total_engines,vt_reputation

いい感じにAbuseIPDB と Virus Total の評価結果が表示できていると思います。
splunkbase AbuseIPDB Check(https://splunkbase.splunk.com/app/4903)
AbuseIPDB Splunk+AbuseIPDB(https://www.abuseipdb.com/splunk)
Virus TotalのSplunk用Addonであるvt4splunkを使ってファイルハッシュの調査をしてみたのでここに記録しておきます。
vt4splunk経由で確認するファイルのハッシュ値を準備します。
今回は、MISPにて収集した IoCデータの中から以下の赤枠のハッシュ値でテストしてみることにしました。

なお、MISPではこのハッシュはまず、Payload delivery というタイプで2019-04-10 に配布されており、その後、md5 のタイプで 2019-04-12に配布されているようです。

それでは先ほどのMISPから取り出したハッシュをvt4splunkを使って評価してみます。
Search画面から以下のコマンドを打つと、testhashで指定したファイルハッシュに対する Virus Totalでの評価結果を検索結果の一部として表示することができるようになります。

これをみるとこのハッシュが最初に報告されたのが、2019-04-12 となっています。
ほぼ同時期ですが、Payload delivery というタイプでMISPを確認しておけば、2日早くこのファイルをハッシュにて検知できていたようですね。
先日SplunkにインストールしたVirusTotal Addon(vt4splunk)の使い勝手を再確認してみました。
すると思いがけず、VirusTotalのスコアが6/88の通信が発生していたので詳細を確認してみました。
とりあえず SplunkのStreamで収集しているhttp ログとVirusTotalの評価を突き合わせてみました。
sourcetype=stream:http | vt4splunk ip=dest_ip | table _time,dest_ip, vt_detections,vt_total_engines,vt_reputation,vt_info
すると、VirusTotalのスコアが1/88の通信先への通信が発生している様子。

まあ、googleも2/88だったりするし(たしか)、そんなこともありますよね。
そう思いながら vt4splunk のダッシュボードを見たところ、「Flaged IP Address」が11件発生しておりその中の一つは6/88のスコア。。。

そこで、リスト右端の「open」からVirusTotalの詳細な情報を確認。malicious や malware というワードが書かれているので、ちょっと不安に。。。

画面を下にスクロールして通信のログを確認。どうやらubuntsuのサイトにいっているらしい。VMでMISPを動かしていてそのOSがubuntsuなので、そいつがいっているのかも。

ちなみに11件という値をたたき出しているSPL文はこのようになっていました。うーん、むずい。。。
| inputlookup vt_ip_cache | search vt_detections > 0 | where "1" = "1" OR _first_seen_in_events >= relative_time(now(), "1")
| join type=left vt_id [| inputlookup vt_ignore_cache | search vt_type=ip] | where isnull(vt_type) | stats count
そこでChatGPTにこのSPL文を解説していただきました。
以下、ChatGPTの解説です。
このSPL(Splunk Processing Language)クエリは、Splunkデータベース内の`vt_ip_cache`と`vt_ignore_cache`という2つのテーブルからデータを取得し、さまざまな操作を行っています。以下に各行の意味を説明します。 1. `inputlookup vt_ip_cache`: `vt_ip_cache`テーブルからデータを取得します。 2. `search vt_detections > 0`: `vt_detections`フィールドが0より大きい行を検索します。 3. `where "1" = "1" OR _first_seen_in_events >= relative_time(now(), "1")`: 条件式が常に真となるため、すべての行をフィルタリングします。また、`_first_seen_in_events`フィールドの値が現在の時刻から1つの時間単位以上前である場合にも行をフィルタリングします。 4. `join type=left vt_id [| inputlookup vt_ignore_cache | search vt_type=ip]`: `vt_ignore_cache`テーブルから`vt_type`フィールドが"ip"の行を取得し、`vt_id`フィールドを使用して`vt_ip_cache`テーブルと結合します。結合は左外部結合(Left Join)です。 5. `where isnull(vt_type)`: 結合した後、`vt_type`フィールドが存在しない(NULL)行のみをフィルタリングします。 6. `stats count`: 結果の行数をカウントします。 このクエリの目的は、`vt_ip_cache`テーブルから検出数が0より大きい行を取得し、一定の条件に基づいてデータをフィルタリングします。さらに、`vt_ignore_cache`テーブルとの結合を行い、`vt_type`フィールドが存在しない(NULL)行の数をカウントします。
前回、MISPのAddon(MISP42)をSplunkにインストールし、イベントIDでMISPの検索を行ってみました。
しかしながら実際のインシデント調査では、調査の中で抽出したIoCがMISPに登録されていないか確認することが多いのではないかと思います。
そこで今回は、md5 や 通信先のIPアドレスをキーにMISPのデータを検索する方法を確認してみました。
MISP custom command のプルダウンメニューから「mispsearch」を選択すると、IoCのタイプを指定してMISP内のデータを検索することができます。

下の画面は、md5を指定してMISPを検索しているものになり、各パラメタについては
misp_instance:misp_instance01 field:md5 includeEventTags:True Paste your sample query here:| makeresults | eval md5="61e3571b8d9b2e9ccfadc3dde10fb6e1"
と設定しています。

またこの検索結果の下部から以下の画面の通り「サーチで開く」を選択すると、SPLでのサーチ文を確認することができます。

なお、この時のサーチ文は以下の通りとなっていました。
| makeresults | eval md5="61e3571b8d9b2e9ccfadc3dde10fb6e1" | search md5=61e3571b8d9b2e9ccfadc3dde10fb6e1 | mispsearch misp_instance=misp_instance01 field=md5 includeEventTags="true"
念のため、検索で表示された misp_event_id : 1057 をMISPのコンソールでも確認したところ、下の画面の通り、id:1057に同じ md5が含まれていました。

同じ要領で、送信先IPアドレスでも検索が行えます。
以下は送信先「37.120.170[.]231」に対するSPLでの検索例です。(このアドレスにアクセスしないように!)
| makeresults | eval ip-dst="37.120.170.231" | mispsearch misp_instance=misp_instance01 field=ip-dst includeEventTags="true" includeEventUuid="false" to_ids="false"
以下はMISPの「Comment」にEmotetと書かれているイベントを検索している例です。
| makeresults | eval misp_comment="Emotet" | mispsearch misp_instance=misp_instance01 field=misp_comment includeEventTags="true" includeEventUuid="false" to_ids="false"
Splunkにログを集約している企業などでは、同じSplunkコンソールからMISPのIoCを検索できるようになるので便利かもしれませんね。
こういった状況になることは普通はないと思いますが、Splunk 管理ポート(デフォルトはTCP:8089)を変えてしまい、Virus Total の Addon からVirus Totalのサイトへのソケット接続に失敗するようになってしまったので、教訓として記載しておきます。
Splunk の検索フィールドから以下のSPL文を実行させようとしました。
| makeresults | eval testip="8.8.8.8" | vt4splunk ip=testip
すると、以下のエラーが発生しました。
ConnectionRefusedError at /Applications/Splunk/lib/python3.7/socket.py, line 716 : [Errno 61] Connection refused
以下の設定ファイルの編集し、管理ポートを8089に戻します。
/Applications/Splunk/etc/system/local/web.conf
設定ファイルの中身は以下のようになっていて、「mgmtHostPort」のところで管理ポートが指定されています。
[settings] enableSplunkWebSSL = 0 mgmtHostPort = 127.0.0.1:8089
この後、Splunkを再起動すると問題なく「vt4splunk」のコマンドが使えるようになりました。
Splunkbase に Shodan へのアクセスする為にaddon がなかったので、インターネットの情報を見ながら Splunk Addon Builder を使って作ってみました。
REST APIへのアクセスし定期的にデータを取ってくるだけであれば30分くらいで作成できたので共有しておきます。
Splunk Addon Builderの画面から「New Add-on」を選択します。

すると以下の画面が表示されるので、「Configure Data Collection」を選択します。

次にAddonの名前を決めます。

そしてデータのインプット方法を聞かれるので左端の「REST API」を選択します。

次に、sourcetypeなどを設定していきます。

そして、REST APIでどんな情報をサーバに投げてデータをGETするかを設定します。
ここではサンプルとして2つ記載しておきます。
(1)指定したIPアドレスの情報を取得するサンプル
https://api.shodan.io/shodan/host/8.8.8.8?key=(API Kye)

(2)ポート22が空いている日本のドメイントップ100を取得する場合
https://api.shodan.io/shodan/host/count?key=(API Key)&query=port:22 country:JP&facets=domain:100

「テスト」ボタンでデータが正しく取得できることを確認したが、「保存」ボタンを押します。
この後、Splunkの再起動を手動で行う必要がありますので注意してください。
ちなみに私の環境(Mac)では以下のコマンドでSplunkの再起動を行いました。
/Applications/Splunk/bin/splunk restart
「Create New Input」ボタンを押し、入力の名前やデータ取得間隔をあらためて設定します。(なぜあらためて入力させているのかは不明。。。)

すると指定した間隔でデータを取得してくれるので、トップのメニューバーから「サーチ」を選択し、以下のようなサーチ文を入力します。
sourcetype="shodan-ssh"
| table facets.domain{}.value, facets.domain{}.count
すると定期的に取得したデータを元に以下のような検索結果を表示してくれます。

・SplunkのAdd-on Builderで自前のアドオンを作成してみる(REST API編)-クラスメソッド株式会社-(https://dev.classmethod.jp/articles/splunk-add-on-builder-rest-api/)
・Shodan API Reference – Shodan- (https://developer.shodan.io/api)
Virus TotalのSplunk用Addonであるvt4splunkを使ってみたのでここに記録しておきます。
vt4splunkをSplunkにインストール後、Search画面から以下のコマンドを打つと、testipで指定したIPアドレスに対する Virus Totalでの評価結果を検索結果の一部として表示することができるようになります。
| makeresults | eval testip="8.8.8.8" | vt4splunk ip=testip

念のため、Virus Totalでも 8.8.8.8 の評価結果を確認したところ、上記と同じく2/88という結果が得られました。

なお、上の方法を応用し、以下のようにあるsourcetype で httpの通信が 400(Bad Request)であったログを検索し、その検索結果の中の”dest_ip”をIPアドレスとしてvt4splunkに渡すことも可能でした。
sourcetype="stream:http" status=400 | vt4splunk ip=dest_ip | table _time,dest_ip, vt_detections,vt_total_engines,vt_reputation,vt_info
なお、この実行結果は以下の通りです。

<参考文献>
hiro_ さんのツイート(https://twitter.com/papa_anniekey/status/1593064221235097600)