先日、以下の通りロードスターのループパネルの塗装剥がれについて、見積もりをいただきました。
そこそこ金額だったので2ヶ月くらい保留にしていたのですが、ようやく塗り直してもらうことを決意し、修正をお願いしてきました。
その結果がこちらです!

めっちゃ綺麗になってとても満足です。
WHY DON'T YOU DO YOUR BEST!!
先日、以下の通りロードスターのループパネルの塗装剥がれについて、見積もりをいただきました。
そこそこ金額だったので2ヶ月くらい保留にしていたのですが、ようやく塗り直してもらうことを決意し、修正をお願いしてきました。
その結果がこちらです!

めっちゃ綺麗になってとても満足です。
MISP には複数のイベントでIoCが一致していないかチェックする機能があります。
それをうまく利用すれば、インシデント調査で収集したIoCが外部から収集したIoCと一致していないか、また、外部から新たに収集したIoCが、過去のインシデント調査した際のIoCと一致していないかを確認することが可能です。
以下の通り、インシデント対応で抽出したIoCを「Add Event」から登録します。
なお、インシデント対応で抽出したIoCを登録する際はイベント名を「SOC-Insident 001」などとするとわかりやすいと思います。

上記画面で「Submit」後に、下図の赤枠で囲った部分にあるアイコン(populate using the Freetext Import tool)をクリックします。

すると以下のようなFreetext Import Tool のポップアップが表示されるので、インシデント対応の中で収集したIoCをペーストし、「Submit」します。

このツールはとても優秀で、IoC 以外の情報もまとめて放り込んでも、綺麗にIoCだけ抽出し、以下の通りピックアップしてくれます。

Freetext での取り込み結果を確認し、問題なければ「Submit attributes」ボタンを押します。
インシデント調査で収集したIoCの登録が完了すると、すでに登録されているイベントのIoCと重複していないか、赤枠の通り表示してくれます。

また重複している場合は、「+Correlation Graph」を選択することで、重複しているイベントとの相関図を以下のとおり表示してくれます。

なお、標的型攻撃などの場合には、インシデント調査で抽出したIoCが各Feed提供元のIoCリストにはまだ登録されていない、といったこともままあると思います。
したがって、新しくFeed提供元からIoCを取得した際に、そのIoCがすでにインシデント対応で抽出していたIoCと一致していないか確認する、といった使い方も可能です。

ちなみに、他のイベントとIoCが重なった数はイベントリストの「Corr」カラムに記載されていますので、探しやすいと思います。

MISP をインストールした初期状態だと、以下の2つのIoC Feed取得元しか登録されていません。

そこで、このFeed元を増やす方法を確認しましたので、ここに記録しておきます。
以下のGitHubサイトにFeed元がたくさんかかれたJSONファイルがあるので、その内容をコピーします。
GitHub - MISP/app/files/feed-metadata/defaults.json https://github.com/MISP/MISP/blob/2.4/app/files/feed-metadata/defaults.json
1.でコピーしたFeed元の情報を取り込む為、上のFeeds画面の左ペインから「Import Feeds from JSON」を選択します。
そして先ほどコピーしたJSONを以下のとおりペーストし「ADD」ボタンを押します。

すると以下の通りFeed元が67件読み込まれました。

あとは、Feed元リストの左にあるチェックからFeedを取り込みたい提供元を選択後、上部にある「Fetch and store all feed data」をクリックすれば取り込まれます。
なお、取り込みの状況は「Administration」-「Jobs」から以下の通り確認可能です。

「Administration」-「Scheduled Tasks」で次の取り込み時間を指定することもできるようですが、毎回設定したいといけないように見えます。
そこで、cronjob と MISPのAPIを使った定期的なFeed元からの取り込み方法が以下のサイトに記載されていますので、興味のある方は参照してみると良いと思います。
Part 10. MISP Threat Intel(SOCFortress) https://socfortress.medium.com/part-10-misp-threat-intel-68131b18f719
k2-ornataのkuroです。
窓際で育てているアデニア・グラウカ、朝日を浴びてなにやらピカっと光るものが見えました。

よく見ると、葉の根元に今にも滴り落ちそうな大きな雫がついていました。
粘り気があり、舐めてみると甘くて苦みがありました。蜜です。

そういえば、たしかに昨年も蜜が出てました。ただ今回ほどではなく、ほんの少しだけでした。今年はなぜか大量生産。元気ならいいのですが。。
アデニア・グラウカは、南アフリカ原産のトケイソウ科の塊根植物(コーデックス)です。柔らかい葉と淡いグリーン色をしたすべすべの木肌が爽やかで清潔感があります。
冬は冬眠をするので11月~3月頃は完全に断水し、それ以外の季節も忘れた頃に水をあげるくらいで、ほぼ放置状態です。
手のかからない、とってもいいコです。
先日OpenCTIとMISPを連携させてみました。
その後、IoCデータが溜まってきているようなので、OpenCTIの使い勝手を少し確認してみましたので、その様子を記録しておきます。
内部でElasticを使っているせいなのか、全般的にとてもいかした画面で、SOCの大画面に投影しても映えそうです。
情報としては、集まってきているIoCの種類や数、そしてIoCに関連する攻撃グループの情報が表示されています。

こちらは上の画面の攻撃グループのグラフから、Turlaを選択した時の画面です。
この攻撃グループの概要やIoC提供者の情報が表示されています。

上の画像からトップメニューの「knowledge」を選択すると、この攻撃グループが保有するC2サイトなどの武器情報が表示されます。
表示がタイムラインになっていて、下にスクロールするほど新しい情報になるようです。

上の画像からトップメニューの「Indicators」を選択すると、その攻撃グループに関連するIoCもリストで確認できます。

また、攻撃グループの一覧をパネル形式で確認することも可能です。

先日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を検索できるようになるので便利かもしれませんね。
前回、OpenCTIを構築し、MISPと連携するところまで実施しました。
そこで今回はさらに、VirusTotalとShodanを連携させてみて、OpenCTIから確認できる情報がどうかわるか確認してみました。
MISPの時と同様に GitHubの以下のサイトから VirusTotalのdocker-compose.yml をコピーし、OpenCTIのdocker-compose.ymlに埋め込みます。
OpenCTI-Platform /connectors https://github.com/OpenCTI-Platform/connectors/tree/master/internal-enrichment/virustotal
そして以下のコマンドを実行します。
docker-compose up -d --build
すると以下の通り既存のコネクタを含めたアップデートとインストールが行われます。

このあとOpenCTIのコンソールを見ると、VirusTotalが追加されていることが確認できました。

shodanのコネクタについても同様の手順で行います。
VirusTotalとShodanをインストールしたら、IoCを表示する画面の右端になる「エンリッチメント」のボタンを押してみました。

すると右側からウィンドウがせり出してきて、VirusTotal とShodanの連携情報が表示されるようになっていました。(IoCによって出たり出なかったりするようですが。)

しかしながら、それ以外の変化が見つけられなかったので、あとでもう少し調べてみようと思っています。
また今後は、cve や Miter ATT&CK とも連携させて、どんな情報が得られるようになるのか確認したいと思っています。
以下のYoutubeでOpenCTIの操作方法が説明されていますので、OpenCTIでざっくりどんなことができるか知りたい人は参考になると思います。
先日、MacのParalleles Desktop上にそれぞれ別サーバとして構築したMISPとOpenCTIを連携させてみたのでここにその方法を記載しておきます。
なお、以下に書いたとおり、OpenCTIを構築する場合、コマンドラインから構築する方法と、portainer.io経由で構築する方法があるようです。
私の場合はコマンドラインから構築しました。(portainer.io経由でもやってみましたが、今のところ私の環境では成功していません。)
コマンドラインから構築する場合は、こちらの方のサイトが参考になると思います。
Re:ゼロから始めるOpenCTI 導入編(Zenn) https://zenn.dev/daiya/articles/658a4f4811e2fa
portainer.io 経由で構築したいという方は、こちらのサイトが参考になると思います。
OPENCTI INSTALLATION (blog agood cloud) https://blog.agood.cloud/posts/2020/04/22/opencti-installation/
OpenCTIが正常に構築できていることを確認した後、以下のGithubのサイトにmisp接続用のdocker-compose.ymlが置いてありますので、取りに行きます。
https://github.com/OpenCTI-Platform/connectors/blob/master/external-import/misp/docker-compose.yml
そのymlの3行目から最後(47行目)までをコピーします。
1 version: '3' 2 services: 3 connector-misp: 4 image: opencti/connector-misp:5.8.7 5 environment: ・・・ 46 - MISP_INTERVAL=5 # Required, in minutes 47 restart: always
1.でコピーしたデータを OpenCTI用のdocker-compose.ymlの中に貼り付けます。
なお、docker-compose.ymlの場所は、openctiをどのディレクトリ配下に構築したかに依存しますが、私の場合、/usr/local/openctiというディレクトリを作って構築したので、その下のdockerディレクトリ の中にありました。
docker-compose.ymlをviなどで開いた後、以下のように「connector-import-document」のセクションの直後に先ほどコピーした「connector-misp」のセクションを挿入します。
・・・
connector-import-document:
image: opencti/connector-import-document:5.8.3
environment:
- OPENCTI_URL=http://opencti:8080
- OPENCTI_TOKEN=${OPENCTI_ADMIN_TOKEN}
- CONNECTOR_ID=${CONNECTOR_IMPORT_DOCUMENT_ID} # Valid UUIDv4
・・・
restart: always
depends_on:
- opencti
connector-misp:
image: opencti/connector-misp:5.8.3
environment:
- OPENCTI_URL=http://opencti:8080
- OPENCTI_TOKEN=${OPENCTI_ADMIN_TOKEN}
- CONNECTOR_ID=(UUIDv4を取得し設定)⭐️
- CONNECTOR_TYPE=EXTERNAL_IMPORT
・・・
- CONNECTOR_LOG_LEVEL=info
- MISP_URL=https://(MISPサーバのIPアドレスを設定)⭐️
- MISP_REFERENCE_URL= # Optional, will be used to create external reference to MISP event (default is "url")
- MISP_KEY=(MISPのAPIキーを設定)⭐️
- MISP_SSL_VERIFY=false # Required
・・・
- MISP_INTERVAL=1 # Required, in minutes
restart: always
depends_on:
- opencti
volumes:
esdata:
s3data:
redisdata:
amqpdata:
「connector-misp」のセクションを挿入したら、環境に合わせて修正をしますが、通常は⭐️をつけた3つの部分だけ変更した方がよいです。
なお、最初の⭐️の部分のUUIDv4ってなに?って感じの人(私もそんな1人です)もいると思いますが、以下のサイトから生成した世界に一つ?のIDをコピーしてくるだけで大丈夫です。
Online UUID Generator https://www.uuidgenerator.net/version4
それ以外を編集するとたぶんハマると思います。
たとえば「OPENCTI_URL」「OPENCTI_TOKEN」あたりを変えたくなるかもしれませんが、それを変えてしまった為に私はすこしハマりました。
上記のymlファイルを編集した後、 OpenCTIを再起動すれば変更が反映されるとおもっていました。
しかし実はそうではなく、再ビルドのコマンドを実行する必要があるようです。そのコマンドがこちらです。
$ docker-compose up -d --build
これを知らなかったが為に、いくらymlファイルを修正してもうまくいかず、かなりハマってしまいました。
以下のZenn様のページが参考になりました、ありがとうございました。
Re:ゼロから始めるOpenCTI External Input Connector編(Zenn) https://zenn.dev/daiya/articles/ce1c3ad92c53aa
うまく設定できていれば OpenCTIダッシュボードの「Data」-「Connector」に以下のとおりMISPが表示されその横のマークがグリーンになっているはずです。

以下を試してみるといいかもしれません。
OpenCTIをインストールしたマシンに、portainer.ioを入れてみましょう。これによりDockerの状態がGUIで見れるようになり、問題点がわかりやすくなります。

正直あまり根拠はありません(MISPとの接続にhttps接続が必要だったので関係あるかなと思っているくらいです)が、以下のコマンドをOpenCTIのサーバ上で打ってみるといいかもしれません。
sudo apt-get install \
apt-transport-https \
ca-certificates \
curl \
gnupg-agent \
software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
それぞれのコマンドの詳しい説明は冒頭に紹介した「OPENCTI INSTALLATION (blog agood cloud)」を見てください。
こういった状況になることは普通はないと思いますが、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」のコマンドが使えるようになりました。